Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

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

@@ -26,7 +26,7 @@ Oppure rimuovi semplicemente l'uso dell'autorizzatore.
 
 ### Chiavi API
 
-Se vengono utilizzate chiavi API, potresti leakarle per mantenere la persistenza o persino crearne di nuove.\
+Se vengono utilizzate chiavi API, potresti leakare per mantenere la persistenza o persino crearne di nuove.\
 Oppure rimuovi semplicemente l'uso delle chiavi API.
 
 {{#include ../../../banners/hacktricks-training.md}}

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

@@ -1,4 +1,4 @@
-# AWS - Cognito Persistence
+# AWS - Persistenza Cognito
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -29,7 +29,7 @@ Controlla come eseguire queste azioni in
 
 ### `cognito-idp:SetRiskConfiguration`
 
-Un attaccante con questo privilegio potrebbe modificare la configurazione del rischio per poter effettuare il login come utente Cognito **senza attivare allarmi**. [**Controlla il cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) per verificare tutte le opzioni:
+Un attaccante con questo privilegio potrebbe modificare la configurazione del rischio per poter effettuare il login come utente Cognito **senza che vengano attivati allarmi**. [**Controlla il cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) per verificare tutte le opzioni:
 ```bash
 aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
 ```

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

@@ -38,7 +38,7 @@ Per mantenere la persistenza, l'attaccante può creare o modificare elementi nel
 
 ### DynamoDB come canale C2
 
-Un attaccante può utilizzare una tabella DynamoDB come **canale di comando e controllo (C2)** creando elementi contenenti comandi e utilizzando istanze compromesse o funzioni Lambda per recuperare ed eseguire questi comandi.
+Un attaccante può utilizzare una tabella DynamoDB come un **canale di comando e controllo (C2)** creando elementi contenenti comandi e utilizzando istanze compromesse o funzioni Lambda per recuperare ed eseguire questi comandi.
 ```bash
 # Create a DynamoDB table for C2
 aws dynamodb create-table \

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

@@ -12,7 +12,7 @@ Per ulteriori informazioni controlla:
 
 ### Persistenza del Tracciamento delle Connessioni del Gruppo di Sicurezza
 
-Se un difensore scopre che un **istanza EC2 è stata compromessa**, probabilmente cercherà di **isolare** la **rete** della macchina. Potrebbe farlo con un esplicito **Deny NACL** (ma i NACL influenzano l'intera subnet), o **cambiando il gruppo di sicurezza** per non consentire **alcun tipo di traffico in entrata o in uscita**.
+Se un difensore scopre che un **EC2 instance è stata compromessa**, probabilmente cercherà di **isolare** la **rete** della macchina. Potrebbe farlo con un esplicito **Deny NACL** (ma i NACL influenzano l'intera subnet), o **cambiando il gruppo di sicurezza** per non consentire **alcun tipo di traffico in entrata o in uscita**.
 
 Se l'attaccante aveva una **reverse shell originata dalla macchina**, anche se il SG è modificato per non consentire traffico in entrata o in uscita, la **connessione non verrà interrotta a causa di** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
 
@@ -21,20 +21,20 @@ Se l'attaccante aveva una **reverse shell originata dalla macchina**, anche se i
 Questo servizio consente di **programmare** la **creazione di AMI e snapshot** e persino di **condividerli con altri account**.\
 Un attaccante potrebbe configurare la **generazione di AMI o snapshot** di tutte le immagini o di tutti i volumi **ogni settimana** e **condividerli con il suo account**.
 
-### Istanze Programmate
+### Istanza Programmata
 
 È possibile programmare le istanze per essere eseguite quotidianamente, settimanalmente o persino mensilmente. Un attaccante potrebbe eseguire una macchina con privilegi elevati o accesso interessante dove potrebbe accedere.
 
-### Richiesta di Spot Fleet
+### Richiesta Spot Fleet
 
-Le istanze Spot sono **più economiche** delle istanze regolari. Un attaccante potrebbe lanciare una **piccola richiesta di spot fleet per 5 anni** (ad esempio), con **assegnazione automatica di IP** e un **user data** che invia all'attaccante **quando l'istanza spot inizia** e l'**indirizzo IP** e con un **ruolo IAM con privilegi elevati**.
+Le istanze Spot sono **più economiche** delle istanze regolari. Un attaccante potrebbe lanciare una **piccola richiesta di spot fleet per 5 anni** (ad esempio), con **assegnazione automatica dell'IP** e un **user data** che invia all'attaccante **quando l'istanza spot inizia** e l'**indirizzo IP** e con un **ruolo IAM con privilegi elevati**.
 
 ### Istanze Backdoor
 
 Un attaccante potrebbe accedere alle istanze e backdoorarle:
 
 - Utilizzando un tradizionale **rootkit** ad esempio
-- Aggiungendo una nuova **chiave SSH pubblica** (controlla [opzioni di privesc EC2](../aws-privilege-escalation/aws-ec2-privesc.md))
+- Aggiungendo una nuova **chiave SSH pubblica** (controlla [EC2 privesc options](../aws-privilege-escalation/aws-ec2-privesc.md))
 - Backdooring il **User Data**
 
 ### **Configurazione di Lancio Backdoor**

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

@@ -16,7 +16,7 @@ Un attaccante potrebbe **caricare un'immagine Docker contenente codice maligno**
 
 ### Politica del Repository
 
-Aggiungi una politica a un singolo repository concedendoti (o a tutti) accesso a un repository:
+Aggiungi una politica a un singolo repository che ti concede (o a tutti) accesso a un repository:
 ```bash
 aws ecr set-repository-policy \
 --repository-name cluster-autoscaler \
@@ -49,7 +49,7 @@ aws ecr set-repository-policy \
 
 <figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
 
-Prima, è necessario concedere all'account esterno accesso al registro con una **politica del registro** come:
+Innanzitutto, è necessario concedere all'account esterno accesso al registro con una **politica del registro** come:
 ```bash
 aws ecr put-registry-policy --policy-text file://my-policy.json
 
@@ -68,7 +68,7 @@ aws ecr put-registry-policy --policy-text file://my-policy.json
 "Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
 }
 ```
-Poi applica la configurazione di replicazione:
+Quindi applica la configurazione di replicazione:
 ```bash
 aws ecr put-replication-configuration \
 --replication-configuration file://replication-settings.json \

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

@@ -1,4 +1,4 @@
-# AWS - ECS Persistence
+# AWS - Persistenza ECS
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -44,12 +44,12 @@ aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
 }
 ]'
 ```
-### Backdoor Container in Existing ECS Task Definition
+### Contenitore Backdoor nella Definizione di Task ECS Esistente
 
 > [!NOTE]
 > TODO: Test
 
-Un attaccante può aggiungere un **container backdoor furtivo** in una definizione di task ECS esistente che viene eseguito insieme ai container legittimi. Il container backdoor può essere utilizzato per la persistenza e per eseguire attività malevole.
+Un attaccante può aggiungere un **contenitore backdoor furtivo** in una definizione di task ECS esistente che viene eseguito insieme a contenitori legittimi. Il contenitore backdoor può essere utilizzato per la persistenza e per svolgere attività malevole.
 ```bash
 # Update the existing task definition to include the backdoor container
 aws ecs register-task-definition --family "existing-task" --container-definitions '[

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

@@ -1,4 +1,4 @@
-# AWS - Elastic Beanstalk Persistence
+# AWS - Persistenza di Elastic Beanstalk
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -22,12 +22,12 @@ Un attaccante potrebbe inserire una backdoor nel codice all'interno del reposito
 
 Invece di modificare il codice sulla versione attuale, l'attaccante potrebbe distribuire una nuova versione dell'applicazione con backdoor.
 
-### Abuso dei Custom Resource Lifecycle Hooks
+### Abuso degli Hook del Ciclo di Vita delle Risorse Personalizzate
 
 > [!NOTE]
 > TODO: Test
 
-Elastic Beanstalk fornisce lifecycle hooks che ti permettono di eseguire script personalizzati durante il provisioning e la terminazione dell'istanza. Un attaccante potrebbe **configurare un lifecycle hook per eseguire periodicamente uno script che esfiltra dati o mantiene l'accesso all'account AWS**.
+Elastic Beanstalk fornisce hook del ciclo di vita che consentono di eseguire script personalizzati durante la provisioning e la terminazione dell'istanza. Un attaccante potrebbe **configurare un hook del ciclo di vita per eseguire periodicamente uno script che esfiltra dati o mantiene l'accesso all'account AWS**.
 ```bash
 bashCopy code# Attacker creates a script that exfiltrates data and maintains access
 echo '#!/bin/bash

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

@@ -15,9 +15,9 @@ Per ulteriori informazioni accedi a:
 - Crea un utente
 - Aggiungi un utente controllato a un gruppo privilegiato
 - Crea chiavi di accesso (del nuovo utente o di tutti gli utenti)
-- Concedi permessi extra a utenti/gruppi controllati (policy collegate o policy inline)
+- Concedi permessi extra a utenti/gruppi controllati (politiche collegate o politiche inline)
 - Disabilita MFA / Aggiungi il tuo dispositivo MFA
-- Crea una situazione di catena di ruoli (maggiore dettagli su questo di seguito nella persistenza STS)
+- Crea una situazione di Role Chain Juggling (ulteriori informazioni su questo di seguito nella persistenza STS)
 
 ### Politiche di fiducia del ruolo backdoor
 
@@ -36,11 +36,11 @@ Potresti inserire una backdoor in una politica di fiducia per poterla assumere p
 ]
 }
 ```
-### Backdoor Policy Version
+### Versione della Politica di Backdoor
 
-Dai permessi di Amministratore a una policy che non è nella sua ultima versione (l'ultima versione dovrebbe sembrare legittima), quindi assegna quella versione della policy a un utente/gruppo controllato.
+Dai permessi di Amministratore a una politica che non è l'ultima versione (l'ultima versione dovrebbe apparire legittima), quindi assegna quella versione della politica a un utente/gruppo controllato.
 
-### Backdoor / Create Identity Provider
+### Backdoor / Crea Provider di Identità
 
 Se l'account sta già fidandosi di un provider di identità comune (come Github), le condizioni della fiducia potrebbero essere aumentate in modo che l'attaccante possa abusarne.
 

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

@@ -18,7 +18,7 @@ Un attaccante potrebbe utilizzare il permesso **`kms:PutKeyPolicy`** per **dare
 
 I grant sono un altro modo per dare a un principale alcuni permessi su una chiave specifica. È possibile concedere un grant che consente a un utente di creare grant. Inoltre, un utente può avere diversi grant (anche identici) sulla stessa chiave.
 
-Pertanto, è possibile per un utente avere 10 grant con tutti i permessi. L'attaccante dovrebbe monitorare questo costantemente. E se a un certo punto 1 grant viene rimosso, dovrebbero essere generati altri 10.
+Pertanto, è possibile che un utente abbia 10 grant con tutti i permessi. L'attaccante dovrebbe monitorare questo costantemente. E se a un certo punto 1 grant viene rimosso, altri 10 dovrebbero essere generati.
 
 (Stiamo usando 10 e non 2 per poter rilevare che un grant è stato rimosso mentre l'utente ha ancora alcuni grant)
 ```bash

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

@@ -10,7 +10,7 @@ Per ulteriori informazioni controlla:
 ../../aws-services/aws-lambda-enum.md
 {{#endref}}
 
-### Persistenza dei Layer Lambda
+### Persistenza del Lambda Layer
 
 È possibile **introdurre/backdoor un layer per eseguire codice arbitrario** quando il lambda viene eseguito in modo furtivo:
 
@@ -18,9 +18,9 @@ Per ulteriori informazioni controlla:
 aws-lambda-layers-persistence.md
 {{#endref}}
 
-### Persistenza delle Estensioni Lambda
+### Persistenza dell'Estensione Lambda
 
-Abusando dei Layer Lambda è anche possibile abusare delle estensioni e persistere nel lambda ma anche rubare e modificare le richieste.
+Abusando dei Lambda Layers è anche possibile abusare delle estensioni e persistere nel lambda ma anche rubare e modificare le richieste.
 
 {{#ref}}
 aws-abusing-lambda-extensions.md
@@ -45,7 +45,7 @@ In questo modo un attaccante potrebbe creare una **versione 1 backdoored** e una
 1. Copia il codice originale del Lambda
 2. **Crea una nuova versione backdooring** il codice originale (o solo con codice malevolo). Pubblica e **deplora quella versione** su $LATEST
 1. Chiama l'API gateway relativo al lambda per eseguire il codice
-3. **Crea una nuova versione con il codice originale**, Pubblica e deploara quella **versione** su $LATEST.
+3. **Crea una nuova versione con il codice originale**, Pubblica e deplo quella **versione** su $LATEST.
 1. Questo nasconderà il codice backdoored in una versione precedente
 4. Vai all'API Gateway e **crea un nuovo metodo POST** (o scegli un altro metodo) che eseguirà la versione backdoored del lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
 1. Nota il finale :1 dell'arn **che indica la versione della funzione** (la versione 1 sarà quella backdoored in questo scenario).
@@ -54,11 +54,11 @@ In questo modo un attaccante potrebbe creare una **versione 1 backdoored** e una
 
 ### Attuatore Cron/Event
 
-Il fatto che puoi far **eseguire funzioni lambda quando accade qualcosa o quando passa del tempo** rende lambda un modo piacevole e comune per ottenere persistenza ed evitare la rilevazione.\
+Il fatto che puoi far **eseguire funzioni lambda quando accade qualcosa o quando passa del tempo** rende lambda un modo piacevole e comune per ottenere persistenza ed evitare il rilevamento.\
 Ecco alcune idee per rendere la tua **presenza in AWS più furtiva creando lambdas**.
 
 - Ogni volta che viene creato un nuovo utente, lambda genera una nuova chiave utente e la invia all'attaccante.
-- Ogni volta che viene creata una nuova ruolo, lambda concede permessi di assunzione ruolo agli utenti compromessi.
+- Ogni volta che viene creata una nuova funzione, lambda concede permessi di assunzione del ruolo agli utenti compromessi.
 - Ogni volta che vengono generati nuovi log di cloudtrail, cancellali/modificali
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md

@@ -6,7 +6,7 @@
 
 Le estensioni Lambda migliorano le funzioni integrandosi con vari **strumenti di monitoraggio, osservabilità, sicurezza e governance**. Queste estensioni, aggiunte tramite [.zip archivi utilizzando i layer Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) o incluse nelle [distribuzioni di immagini container](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), operano in due modalità: **interna** ed **esterna**.
 
-- **Le estensioni interne** si fondono con il processo di runtime, manipolando il suo avvio utilizzando **variabili d'ambiente specifiche per il linguaggio** e **script wrapper**. Questa personalizzazione si applica a una gamma di runtime, inclusi **Java Correto 8 e 11, Node.js 10 e 12, e .NET Core 3.1**.
+- **Le estensioni interne** si fondono con il processo di runtime, manipolando il suo avvio utilizzando **variabili ambientali specifiche del linguaggio** e **script wrapper**. Questa personalizzazione si applica a una gamma di runtime, inclusi **Java Correto 8 e 11, Node.js 10 e 12, e .NET Core 3.1**.
 - **Le estensioni esterne** vengono eseguite come processi separati, mantenendo l'allineamento operativo con il ciclo di vita della funzione Lambda. Sono compatibili con vari runtime come **Node.js 10 e 12, Python 3.7 e 3.8, Ruby 2.5 e 2.7, Java Corretto 8 e 11, .NET Core 3.1**, e **runtime personalizzati**.
 
 Per ulteriori informazioni su [**come funzionano le estensioni lambda controlla la documentazione**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html).
@@ -15,20 +15,20 @@ Per ulteriori informazioni su [**come funzionano le estensioni lambda controlla
 
 Questo è un riassunto della tecnica proposta in questo post: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
 
-È stato scoperto che il kernel Linux predefinito nell'ambiente di runtime Lambda è compilato con le chiamate di sistema “**process_vm_readv**” e “**process_vm_writev**”. E tutti i processi vengono eseguiti con lo stesso ID utente, anche il nuovo processo creato per l'estensione esterna. **Questo significa che un'estensione esterna ha accesso completo in lettura e scrittura alla memoria heap di Rapid, per design.**
+È stato scoperto che il kernel Linux predefinito nell'ambiente di runtime Lambda è compilato con le chiamate di sistema “**process_vm_readv**” e “**process_vm_writev**”. E tutti i processi vengono eseguiti con lo stesso ID utente, anche il nuovo processo creato per l'estensione esterna. **Questo significa che un'estensione esterna ha pieno accesso in lettura e scrittura alla memoria heap di Rapid, per design.**
 
 Inoltre, mentre le estensioni Lambda hanno la capacità di **iscriversi agli eventi di invocazione**, AWS non rivela i dati grezzi a queste estensioni. Questo garantisce che **le estensioni non possano accedere a informazioni sensibili** trasmesse tramite la richiesta HTTP.
 
-Il processo Init (Rapid) monitora tutte le richieste API su [http://127.0.0.1:9001](http://127.0.0.1:9001/) mentre le estensioni Lambda vengono inizializzate ed eseguite prima dell'esecuzione di qualsiasi codice di runtime, ma dopo Rapid.
+Il processo Init (Rapid) monitora tutte le richieste API a [http://127.0.0.1:9001](http://127.0.0.1:9001/) mentre le estensioni Lambda vengono inizializzate ed eseguite prima dell'esecuzione di qualsiasi codice di runtime, ma dopo Rapid.
 
 <figure><img src="../../../../images/image (254).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png</a></p></figcaption></figure>
 
 La variabile **`AWS_LAMBDA_RUNTIME_API`** indica l'**IP** e il **numero di porta** dell'API Rapid ai **processi di runtime secondari** e alle estensioni aggiuntive.
 
 > [!WARNING]
-> Cambiando la variabile d'ambiente **`AWS_LAMBDA_RUNTIME_API`** in un **`port`** a cui abbiamo accesso, è possibile intercettare tutte le azioni all'interno del runtime Lambda (**man-in-the-middle**). Questo è possibile perché l'estensione viene eseguita con gli stessi privilegi di Rapid Init, e il kernel del sistema consente la **modifica della memoria del processo**, abilitando la modifica del numero di porta.
+> Cambiando la variabile ambientale **`AWS_LAMBDA_RUNTIME_API`** in un **`port`** a cui abbiamo accesso, è possibile intercettare tutte le azioni all'interno del runtime Lambda (**man-in-the-middle**). Questo è possibile perché l'estensione viene eseguita con gli stessi privilegi di Rapid Init, e il kernel del sistema consente la **modifica della memoria del processo**, abilitando la modifica del numero di porta.
 
-Poiché **le estensioni vengono eseguite prima di qualsiasi codice di runtime**, modificare la variabile d'ambiente influenzerà il processo di runtime (ad es., Python, Java, Node, Ruby) mentre si avvia. Inoltre, **le estensioni caricate dopo** la nostra, che si basano su questa variabile, instraderanno anche attraverso la nostra estensione. Questa configurazione potrebbe consentire a malware di bypassare completamente le misure di sicurezza o le estensioni di registrazione direttamente all'interno dell'ambiente di runtime.
+Poiché **le estensioni vengono eseguite prima di qualsiasi codice di runtime**, modificare la variabile ambientale influenzerà il processo di runtime (ad es., Python, Java, Node, Ruby) mentre si avvia. Inoltre, **le estensioni caricate dopo** la nostra, che si basano su questa variabile, verranno anch'esse instradate attraverso la nostra estensione. Questa configurazione potrebbe consentire a malware di bypassare completamente le misure di sicurezza o le estensioni di registrazione direttamente all'interno dell'ambiente di runtime.
 
 <figure><img src="../../../../images/image (267).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png</a></p></figcaption></figure>
 

src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md

@@ -1,18 +1,18 @@
-# AWS - Lambda Layers Persistence
+# AWS - Persistenza delle Lambda Layers
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
 ## Lambda Layers
 
-Un layer Lambda è un archivio .zip che **può contenere codice aggiuntivo** o altro contenuto. Un layer può contenere librerie, un [runtime personalizzato](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), dati o file di configurazione.
+Una Lambda layer è un archivio .zip che **può contenere codice aggiuntivo** o altro contenuto. Una layer può contenere librerie, un [runtime personalizzato](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), dati o file di configurazione.
 
-È possibile includere fino a **cinque layer per funzione**. Quando includi un layer in una funzione, i **contenuti vengono estratti nella directory `/opt`** nell'ambiente di esecuzione.
+È possibile includere fino a **cinque layers per funzione**. Quando includi una layer in una funzione, i **contenuti vengono estratti nella directory `/opt`** nell'ambiente di esecuzione.
 
-Per **definizione**, i **layer** che crei sono **privati** al tuo account AWS. Puoi scegliere di **condividere** un layer con altri account o di **rendere** il layer **pubblico**. Se le tue funzioni consumano un layer pubblicato da un altro account, le tue funzioni possono **continuare a utilizzare la versione del layer dopo che è stata eliminata, o dopo che il tuo permesso di accesso al layer è stato revocato**. Tuttavia, non puoi creare una nuova funzione o aggiornare funzioni utilizzando una versione di layer eliminata.
+Per **definizione**, le **layers** che crei sono **private** al tuo account AWS. Puoi scegliere di **condividere** una layer con altri account o di **rendere** la layer **pubblica**. Se le tue funzioni utilizzano una layer pubblicata da un altro account, le tue funzioni possono **continuare a utilizzare la versione della layer dopo che è stata eliminata, o dopo che il tuo permesso di accesso alla layer è stato revocato**. Tuttavia, non puoi creare una nuova funzione o aggiornare funzioni utilizzando una versione di layer eliminata.
 
-Le funzioni distribuite come immagine del contenitore non utilizzano layer. Invece, impacchetti il tuo runtime preferito, librerie e altre dipendenze nell'immagine del contenitore quando costruisci l'immagine.
+Le funzioni distribuite come immagine del contenitore non utilizzano le layers. Invece, impacchetti il tuo runtime preferito, librerie e altre dipendenze nell'immagine del contenitore quando costruisci l'immagine.
 
-### Python load path
+### Percorso di caricamento di Python
 
 Il percorso di caricamento che Python utilizzerà in lambda è il seguente:
 ```
@@ -31,7 +31,7 @@ Pertanto, i requisiti sono:
 ### Librerie pre-caricate
 
 > [!WARNING]
-> Quando si abusa di questa tecnica ho trovato una difficoltà: Alcune librerie sono **già caricate** nel runtime di python quando il tuo codice viene eseguito. Mi aspettavo di trovare cose come `os` o `sys`, ma **anche la libreria `json` era caricata**.\
+> Quando abuso di questa tecnica ho trovato una difficoltà: Alcune librerie sono **già caricate** nel runtime di python quando il tuo codice viene eseguito. Mi aspettavo di trovare cose come `os` o `sys`, ma **anche la libreria `json` era caricata**.\
 > Per abusare di questa tecnica di persistenza, il codice deve **caricare una nuova libreria che non è caricata** quando il codice viene eseguito.
 
 Con un codice python come questo è possibile ottenere la **lista delle librerie che sono pre-caricate** all'interno del runtime di python in lambda:
@@ -52,9 +52,9 @@ E questa è la lista delle **librerie** che **lambda include installate per impo
 
 ### Backdooring del Lambda Layer
 
-In questo esempio supponiamo che il codice target stia importando **`csv`**. Stiamo per **backdooring l'importazione della libreria `csv`**.
+In questo esempio supponiamo che il codice target stia importando **`csv`**. Stiamo per **inserire un backdoor nell'importazione della libreria `csv`**.
 
-Per fare ciò, creeremo la directory **csv** con il file **`__init__.py`** al suo interno in un percorso caricato da lambda: **`/opt/python/lib/python3.9/site-packages`**\
+Per fare ciò, creeremo la directory csv con il file **`__init__.py`** al suo interno in un percorso caricato da lambda: **`/opt/python/lib/python3.9/site-packages`**\
 Poi, quando il lambda viene eseguito e cerca di caricare **csv**, il nostro **file `__init__.py` verrà caricato ed eseguito**.\
 Questo file deve:
 
@@ -83,7 +83,7 @@ import csv as _csv
 
 sys.modules["csv"] = _csv
 ```
-Poi, crea uno zip con questo codice nel percorso **`python/lib/python3.9/site-packages/__init__.py`** e aggiungilo come un layer lambda.
+Quindi, crea uno zip con questo codice nel percorso **`python/lib/python3.9/site-packages/__init__.py`** e aggiungilo come un layer lambda.
 
 Puoi trovare questo codice in [**https://github.com/carlospolop/LambdaLayerBackdoor**](https://github.com/carlospolop/LambdaLayerBackdoor)
 

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

@@ -18,7 +18,7 @@ aws rds modify-db-instance --db-instance-identifier target-instance --publicly-a
 ```
 ### Crea un utente admin all'interno del DB
 
-Un attaccante potrebbe semplicemente **creare un utente all'interno del DB** in modo che anche se la password dell'utente master viene modificata, **non perde l'accesso** al database.
+Un attaccante potrebbe semplicemente **creare un utente all'interno del DB** così anche se la password dell'utente master viene modificata, **non perde l'accesso** al database.
 
 ### Rendi pubblico lo snapshot
 ```bash

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

@@ -12,7 +12,7 @@ Per ulteriori informazioni controlla:
 
 ### Crittografia lato client KMS
 
-Quando il processo di crittografia è completato, l'utente utilizzerà l'API KMS per generare una nuova chiave (`aws kms generate-data-key`) e **salverà la chiave crittografata generata all'interno dei metadati** del file ([esempio di codice python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) in modo che quando si verifica la decrittazione, possa decrittarla nuovamente utilizzando KMS:
+Quando il processo di crittografia è completato, l'utente utilizzerà l'API KMS per generare una nuova chiave (`aws kms generate-data-key`) e **memorizzerà la chiave crittografata generata all'interno dei metadati** del file ([esempio di codice python](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) in modo che quando si verifica la decrittazione, possa decrittarla nuovamente utilizzando KMS:
 
 <figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
 

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

@@ -12,7 +12,7 @@ Per ulteriori informazioni controlla:
 
 ### Utilizzando la policy delle risorse
 
-In SQS è necessario indicare con una policy IAM **chi ha accesso per leggere e scrivere**. È possibile indicare account esterni, ARN di ruoli, o **anche "\*"**.\
+In SQS è necessario indicare con una policy IAM **chi ha accesso a leggere e scrivere**. È possibile indicare account esterni, ARN di ruoli, o **anche "\*"**.\
 La seguente policy consente a chiunque in AWS di accedere a tutto nella coda chiamata **MyTestQueue**:
 ```json
 {
@@ -32,6 +32,6 @@ La seguente policy consente a chiunque in AWS di accedere a tutto nella coda chi
 }
 ```
 > [!NOTE]
-> Potresti anche **attivare un Lambda nell'account degli attaccanti ogni volta che un nuovo messaggio** viene inserito nella coda (dovresti in qualche modo reinserirlo). Per questo segui queste istruzioni: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
+> Potresti anche **attivare una Lambda nell'account degli attaccanti ogni volta che un nuovo messaggio** viene messo nella coda (dovresti rimetterlo) in qualche modo. Per questo segui queste istruzioni: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
 
 {{#include ../../../banners/hacktricks-training.md}}

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

@@ -28,7 +28,7 @@ aws sts get-session-token \
 
 ### Role Chain Juggling
 
-[**Il chaining dei ruoli è una funzionalità riconosciuta di AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), spesso utilizzata per mantenere la persistenza stealth. Comporta la capacità di **assumere un ruolo che poi assume un altro**, potenzialmente tornando al ruolo iniziale in modo **ciclico**. Ogni volta che un ruolo viene assunto, il campo di scadenza delle credenziali viene aggiornato. Di conseguenza, se due ruoli sono configurati per assumere reciprocamente, questa configurazione consente il rinnovo perpetuo delle credenziali.
+[**Il chaining dei ruoli è una funzionalità riconosciuta di AWS**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), spesso utilizzata per mantenere una persistenza furtiva. Comporta la capacità di **assumere un ruolo che poi assume un altro**, potenzialmente tornando al ruolo iniziale in modo **ciclico**. Ogni volta che un ruolo viene assunto, il campo di scadenza delle credenziali viene aggiornato. Di conseguenza, se due ruoli sono configurati per assumere reciprocamente, questa configurazione consente il rinnovo perpetuo delle credenziali.
 
 Puoi utilizzare questo [**strumento**](https://github.com/hotnops/AWSRoleJuggler/) per mantenere attivo il chaining dei ruoli:
 ```bash