diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
index 31d9f8b48..466258b09 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
@@ -6,9 +6,9 @@
 
 ### `sts:AssumeRole`
 
-Ogni ruolo viene creato con una **role trust policy**, questa policy indica **chi può assumere il ruolo creato**. Se un ruolo dello **stesso account** dichiara che un account può assumerlo, significa che l'account sarà in grado di accedere al ruolo (e potenzialmente **privesc**).
+Ogni ruolo viene creato con una **role trust policy**, questa policy indica **chi può assumere il ruolo creato**. Se un ruolo dello **stesso account** dichiara che un account può assumerlo, significa che l'account sarà in grado di accedere al ruolo (e potenzialmente ottenere **privesc**).
 
-Per esempio, la seguente role trust policy indica che chiunque può assumerla, quindi **qualsiasi utente sarà in grado di privesc** alle autorizzazioni associate a quel ruolo.
+Ad esempio, la seguente role trust policy indica che chiunque può assumerlo, quindi **qualsiasi utente sarà in grado di privesc** alle autorizzazioni associate a quel ruolo.
 ```json
 {
 "Version": "2012-10-17",
@@ -23,20 +23,20 @@ Per esempio, la seguente role trust policy indica che chiunque può assumerla, q
 ]
 }
 ```
-Puoi impersonare un ruolo eseguendo:
+Puoi impersonare un ruolo in esecuzione:
 ```bash
 aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
 ```
-**Impatto potenziale:** Privesc al ruolo.
+**Impatto potenziale:** Privesc al role.
 
 > [!CAUTION]
-> Nota che in questo caso il permesso `sts:AssumeRole` deve essere **indicato nel ruolo da abusare** e non in una policy appartenente all'attaccante.\
-> Con un'eccezione, per **assumere un ruolo da un account diverso** l'account dell'attaccante **deve anche** avere la **`sts:AssumeRole`** sul ruolo.
+> Nota che in questo caso il permesso `sts:AssumeRole` deve essere **indicato nel role da abusare** e non in una policy appartenente all'attacker.\
+> Con un'eccezione, per **assumere un role da un account diverso** l'account attacker **deve anche** avere il **`sts:AssumeRole`** sul role.
 
 
 ### `sts:AssumeRoleWithSAML`
 
-Una trust policy con questo ruolo concede **agli utenti autenticati via SAML l'accesso per impersonare il ruolo.**
+Una trust policy con questo role concede **agli utenti autenticati tramite SAML l'accesso per impersonare il role.**
 
 Un esempio di trust policy con questo permesso è:
 ```json
@@ -63,22 +63,22 @@ Per generare credenziali per impersonare il ruolo, in generale potresti usare qu
 ```bash
 aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
 ```
-Ma **i fornitori** potrebbero avere i **propri strumenti** per rendere questo più semplice, come [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
+Ma i **provider** potrebbero avere i loro **strumenti** per semplificare questo, come [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
 ```bash
 onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
 ```
-**Impatto potenziale:** Privesc to the role.
+**Impatto potenziale:** Privesc al ruolo.
 
 ### `sts:AssumeRoleWithWebIdentity`
 
-Questa autorizzazione permette di ottenere un set di credenziali di sicurezza temporanee per **utenti che sono stati autenticati in un'app mobile, un'applicazione web, EKS...** tramite un provider di identità web. [Ulteriori informazioni qui.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+Questa autorizzazione permette di ottenere un set di credenziali di sicurezza temporanee per **utenti autenticati in mobile, applicazioni web, EKS...** con un provider di identità web. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
 
-Ad esempio, se un **account di servizio EKS** dovrebbe essere in grado di **impersonare un ruolo IAM**, avrà un token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** e può **assumere il ruolo e ottenere credenziali** facendo qualcosa del genere:
+Ad esempio, se un **EKS service account** dovrebbe essere in grado di **impersonare un ruolo IAM**, avrà un token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** e può **assumere il ruolo e ottenere credenziali** facendo qualcosa del genere:
 ```bash
 aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
 # The role name can be found in the metadata of the configuration of the pod
 ```
-### Federation Abuse
+### Abuso della federazione
 
 {{#ref}}
 ../aws-basic-information/aws-federation-abuse.md
@@ -86,9 +86,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
 
 ### IAM Roles Anywhere Privesc
 
-AWS IAM RolesAnywhere permette a workload esterni ad AWS di assumere IAM roles tramite certificati X.509. Tuttavia, quando le trust policies non sono correttamente limitate, possono essere abusate per privilege escalation.
+AWS IAM RolesAnywhere permette a workload esterni ad AWS di assumere ruoli IAM usando certificati X.509. Ma quando le trust policies non sono adeguatamente limitate, possono essere abusate per privilege escalation.
 
-Questa policy non contiene restrizioni su quale trust anchor o quali attributi del certificato sono consentiti. Di conseguenza, qualsiasi certificato legato a qualsiasi trust anchor nell'account può essere utilizzato per assumere questo ruolo.
+Per capire questo attacco, è necessario spiegare cos'è un trust anchor. Un trust anchor in AWS IAM Roles Anywhere è l'entità radice di fiducia: contiene il certificato pubblico di una Certificate Authority (CA) registrata nell'account, in modo che AWS possa validare i certificati X.509 presentati. In questo modo, se il client certificate è stato emesso da quella CA e il trust anchor è attivo, AWS lo riconosce come valido.
+
+Inoltre, un profile è la configurazione che definisce quali attributi del certificato X.509 (come CN, OU o SAN) saranno trasformati in session tags, e questi tags saranno poi confrontati con le condizioni della trust policy.
+
+Questa policy manca di restrizioni su quali trust anchor o attributi del certificato siano consentiti. Di conseguenza, qualsiasi certificato legato a qualsiasi trust anchor nell'account può essere usato per assumere questo ruolo.
 ```json
 {
 "Version": "2012-10-17",
@@ -108,9 +112,9 @@ Questa policy non contiene restrizioni su quale trust anchor o quali attributi d
 }
 
 ```
-Per privesc è richiesto `aws_signing_helper` da https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
+Per privesc, è richiesto il `aws_signing_helper` da https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
 
-Quindi, usando un certificato valido, l'attaccante può pivotare in un ruolo con privilegi più elevati
+Poi, usando un certificato valido, l'attaccante può, facendo pivot, accedere al ruolo con privilegi più elevati
 ```bash
 aws_signing_helper credential-process \
 --certificate readonly.pem \
@@ -119,13 +123,11 @@ aws_signing_helper credential-process \
 --profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
 --role-arn arn:aws:iam::123456789012:role/Admin
 ```
-La trust anchor valida che il certificato client `readonly.pem` provenga dalla sua CA autorizzata; quando la trust anchor è stata creata è stato incluso il certificato pubblico della CA (ora usato per validare `readonly.pem`).
+Il trust anchor valida che il certificato `readonly.pem` del client provenga dalla sua CA autorizzata, e all'interno di questo certificato `readonly.pem` c'è la chiave pubblica che AWS usa per verificare che la firma sia stata fatta con la corrispondente chiave privata `readonly.key`.
 
-All'interno di `readonly.pem` c'è la chiave pubblica, che AWS usa per verificare che la firma sia stata generata con la corrispondente chiave privata `readonly.key`.
+Il certificato fornisce anche attributi (come CN o OU) che il profilo `default` trasforma in tag, i quali la trust policy del ruolo può usare per decidere se autorizzare l'accesso. Se non ci sono condizioni nella trust policy, quegli tag non hanno utilità e l'accesso viene concesso a chiunque possieda un certificato valido.
 
-Il certificato dimostra anche l'identità e fornisce attributi (come CN o OU) che il profilo `default` trasforma in tag; la trust policy del ruolo può usare questi tag per decidere se autorizzare l'accesso. Se non ci sono condizioni nella trust policy, quei tag vengono ignorati e chiunque possieda un certificato valido è autorizzato.
-
-Perché questo attacco sia possibile, sia la trust anchor sia il profilo `default` devono essere attivi.
+Perché questo attacco sia possibile, sia il trust anchor che il profilo `default` devono essere attivi.
 
 ### Riferimenti