Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

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

@@ -63,7 +63,7 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
 - `StartBuild` attiva un singolo lavoro di build utilizzando un specifico `buildspec.yml`.
 - `StartBuildBatch` consente di avviare un batch di build, con configurazioni più complesse (come eseguire più build in parallelo).
 
-**Impatto Potenziale:** Privesc diretto ai ruoli AWS Codebuild attaccati.
+**Impatto Potenziale:** Privesc diretto ai ruoli AWS Codebuild allegati.
 
 ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 

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

@@ -140,7 +140,7 @@ aws ecs run-task \
 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
 Questo scenario è simile ai precedenti ma **senza** il permesso **`iam:PassRole`**.\
-Questo è comunque interessante perché se puoi eseguire un contenitore arbitrario, anche se senza un ruolo, potresti **eseguire un contenitore privilegiato per evadere** al nodo e **rubare il ruolo IAM EC2** e i **ruoli degli altri contenitori ECS** in esecuzione nel nodo.\
+Questo è comunque interessante perché se puoi eseguire un contenitore arbitrario, anche se senza un ruolo, potresti **eseguire un contenitore privilegiato per fuggire** al nodo e **rubare il ruolo IAM EC2** e i **ruoli degli altri contenitori ECS** in esecuzione nel nodo.\
 Potresti persino **forzare altre attività a essere eseguite all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**sezione Privesc to node**](aws-ecs-privesc.md#privesc-to-node)).
 
 > [!WARNING]
@@ -242,7 +242,7 @@ TODO: È possibile registrare un'istanza da un diverso account AWS in modo che l
 ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
 
 > [!NOTE]
-> TODO: Testare questo
+> TODO: Testa questo
 
 Un attaccante con i permessi `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` e `ecs:DescribeTaskSets` può **creare un set di attività malevole per un servizio ECS esistente e aggiornare il set di attività primario**. Questo consente all'attaccante di **eseguire codice arbitrario all'interno del servizio**.
 ```bash

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

@@ -12,9 +12,9 @@ Per ulteriori informazioni su questo servizio AWS, controlla:
 
 ### Risorse delle Attività
 
-Queste tecniche di escalation dei privilegi richiederanno di utilizzare alcune risorse delle funzioni step di AWS per eseguire le azioni di escalation dei privilegi desiderate.
+Queste tecniche di escalation dei privilegi richiederanno l'uso di alcune risorse delle funzioni step di AWS per eseguire le azioni di escalation dei privilegi desiderate.
 
-Per controllare tutte le azioni possibili, puoi andare nel tuo account AWS, selezionare l'azione che desideri utilizzare e vedere i parametri che sta utilizzando, come in:
+Per controllare tutte le azioni possibili, puoi andare al tuo account AWS, selezionare l'azione che desideri utilizzare e vedere i parametri che sta utilizzando, come in:
 
 <figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
 
@@ -29,7 +29,7 @@ Un attaccante con i permessi **`states:TestState`** & **`iam:PassRole`** può te
 ```bash
 aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
 ```
-I seguenti esempi mostrano come testare uno stato che crea una chiave di accesso per l'**`admin`** utente sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente allo stato di eseguire l'azione **`iam:CreateAccessKey`**:
+I seguenti esempi mostrano come testare uno stato che crea una chiave di accesso per l'utente **`admin`** sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente allo stato di eseguire l'azione **`iam:CreateAccessKey`**:
 
 - **stateDefinition.json**:
 ```json
@@ -59,7 +59,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
 "status": "SUCCEEDED"
 }
 ```
-**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbe portare a significative violazioni della sicurezza.
+**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza.
 
 ### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
 
@@ -75,7 +75,7 @@ aws states start-execution --state-machine-arn <value> [--name <value>] [--input
 # Start a Synchronous Express state machine execution
 aws states start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
 ```
-I seguenti esempi mostrano come creare una macchina a stati che crea una chiave di accesso per l'utente **`admin`** ed esfiltra questa chiave di accesso in un bucket S3 controllato dall'attaccante, sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata qualsiasi policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente alla macchina a stati di eseguire le azioni **`iam:CreateAccessKey`** e **`s3:putObject`**.
+I seguenti esempi mostrano come creare una macchina a stati che crea una chiave di accesso per l'utente **`admin`** ed esfiltra questa chiave di accesso in un bucket S3 controllato dall'attaccante, sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente alla macchina a stati di eseguire le azioni **`iam:CreateAccessKey`** e **`s3:putObject`**.
 
 - **stateMachineDefinition.json**:
 ```json
@@ -132,13 +132,13 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
 }
 ```
 > [!WARNING]
-> Il bucket S3 controllato dall'attaccante dovrebbe avere permessi per accettare un'azione s3:PutObject dall'account della vittima.
+> Il bucket S3 controllato dall'attaccante dovrebbe avere i permessi per accettare un'azione s3:PutObject dall'account della vittima.
 
 **Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza.
 
 ### `states:UpdateStateMachine` & (non sempre richiesto) `iam:PassRole`
 
-Un attaccante con il permesso **`states:UpdateStateMachine`** sarebbe in grado di modificare la definizione di una macchina a stati, potendo aggiungere stati stealth aggiuntivi che potrebbero portare a un'escalation dei privilegi. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo.
+Un attaccante con il permesso **`states:UpdateStateMachine`** sarebbe in grado di modificare la definizione di una macchina a stati, potendo aggiungere stati stealth extra che potrebbero portare a un'escalation dei privilegi. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo.
 
 A seconda di quanto permissivo sia il Ruolo IAM associato alla macchina a stati, un attaccante si troverebbe di fronte a 2 situazioni:
 
@@ -151,7 +151,7 @@ aws states update-state-machine --state-machine-arn <value> [--definition <value
 I seguenti esempi mostrano come aggiornare una macchina a stati legittima che invoca semplicemente una funzione Lambda HelloWorld, per aggiungere uno stato extra che aggiunge l'utente **`unprivilegedUser`** al gruppo IAM **`administrator`**. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati aggiornata, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo.
 
 > [!WARNING]
-> Se la macchina a stati non ha un ruolo IAM permissivo associato, sarebbe anche necessaria l'autorizzazione **`iam:PassRole`** per aggiornare il ruolo IAM al fine di associare un ruolo IAM permissivo (ad esempio uno con la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata).
+> Se la macchina a stati non ha un ruolo IAM permissivo associato, sarebbe anche necessario il permesso **`iam:PassRole`** per aggiornare il ruolo IAM al fine di associare un ruolo IAM permissivo (ad esempio uno con la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata).
 
 {{#tabs }}
 {{#tab name="Legit State Machine" }}

src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md

@@ -104,7 +104,7 @@ oppure puoi accedere al bucket visitando: `flaws.cloud.s3-us-west-2.amazonaws.co
 
 #### Provando
 
-Se provi ad accedere a un bucket, ma nel **nome di dominio specifichi un'altra regione** (ad esempio il bucket è in `bucket.s3.amazonaws.com` ma provi ad accedere a `bucket.s3-website-us-west-2.amazonaws.com`, allora ti verrà **indicato il luogo corretto**:
+Se provi ad accedere a un bucket, ma nel **nome del dominio specifichi un'altra regione** (ad esempio il bucket è in `bucket.s3.amazonaws.com` ma provi ad accedere a `bucket.s3-website-us-west-2.amazonaws.com`, allora ti verrà **indicato il luogo corretto**:
 
 ![](<../../../images/image (106).png>)
 
@@ -165,7 +165,7 @@ Se l'errore è "Access Denied" significa che l'ID dell'account era errato.
 
 ### Utilizzo delle email come enumerazione dell'account root
 
-Come spiegato in [**questo post del blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), è possibile verificare se un indirizzo email è associato a un account AWS **cercando di concedere a un'email permessi** su un bucket S3 tramite ACL. Se questo non genera un errore, significa che l'email è un utente root di qualche account AWS:
+Come spiegato in [**questo post del blog**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), è possibile verificare se un indirizzo email è associato a un account AWS **cercando di concedere permessi a un'email** su un bucket S3 tramite ACL. Se questo non genera un errore, significa che l'email è un utente root di qualche account AWS:
 ```python
 s3_client.put_bucket_acl(
 Bucket=bucket_name,