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 f22f92e62..63bd23b43 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`
 
-Every role is created with a **role trust policy**, this policy indicates **who can assume the created role**. If a role from the **same account** says that an account can assume it, it means that the account will be able to access the role (and potentially **privesc**).
+Cada função é criada com uma **política de confiança da função**, essa política indica **quem pode assumir a função criada**. Se uma função da **mesma conta** declara que uma conta pode assumi-la, isso significa que a conta poderá acessar a função (e potencialmente **privesc**).
 
-For example, the following role trust policy indicates that anyone can assume it, therefore **any user will be able to privesc** to the permissions associated with that role.
+Por exemplo, a seguinte política de confiança da função indica que qualquer um pode assumi-la, portanto **qualquer usuário poderá privesc** às permissões associadas a essa função.
 ```json
 {
 "Version": "2012-10-17",
@@ -23,22 +23,22 @@ For example, the following role trust policy indicates that anyone can assume it
 ]
 }
 ```
-Você pode se passar por um role em execução:
+Você pode assumir uma role executando:
 ```bash
 aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
 ```
 **Impacto Potencial:** Privesc para a role.
 
 > [!CAUTION]
-> Observe que neste caso a permissão `sts:AssumeRole` precisa estar **indicada na role a abusar** e não em uma policy pertencente ao atacante.\
-> Com uma exceção, para **assumir uma role de uma conta diferente** a conta do atacante **também precisa** ter o **`sts:AssumeRole`** sobre a role.
+> Note that in this case the permission `sts:AssumeRole` needs to be **indicated in the role to abuse** and not in a policy belonging to the attacker.\
+> With one exception, in order to **assume a role from a different account** the attacker account **also needs** to have the **`sts:AssumeRole`** over the role.
 
 
 ### `sts:AssumeRoleWithSAML`
 
-Uma trust policy com esta role concede **a usuários autenticados via SAML o acesso para assumir a role.**
+Uma trust policy com essa role concede **a usuários autenticados via SAML o acesso para assumir a role.**
 
-Um exemplo de trust policy com essa permissão é:
+Um exemplo de uma trust policy com essa permissão é:
 ```json
 {
 "Version": "2012-10-17",
@@ -63,7 +63,7 @@ Para gerar credenciais para se passar pelo role, em geral você pode usar algo c
 ```bash
 aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
 ```
-Mas os **provedores** podem ter suas **próprias ferramentas** para tornar isso mais fácil, como [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
+Mas **provedores** podem ter suas **próprias ferramentas** para tornar isso mais fácil, como [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
 ```
@@ -71,9 +71,9 @@ onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --
 
 ### `sts:AssumeRoleWithWebIdentity`
 
-Essa permissão permite obter um conjunto de credenciais de segurança temporárias para **usuários que foram autenticados em um aplicativo mobile, web, EKS...** com um provedor de identidade web. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+Essa permissão permite obter um conjunto de credenciais de segurança temporárias para **usuários que foram autenticados em um aplicativo móvel, web, EKS...** com um provedor de identidade web. [Saiba mais aqui.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
 
-Por exemplo, se uma **EKS service account** precisar poder **se passar por um IAM role**, ela terá um token em **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** e pode **assumir a role e obter credenciais** fazendo algo como:
+Por exemplo, se uma **EKS service account** deveria poder **impersonar um IAM role**, ela terá um token em **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** e pode **assumir o role e obter credenciais** fazendo algo como:
 ```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
@@ -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 permite que workloads fora da AWS assumam IAM roles usando certificados X.509. Mas quando trust policies não são devidamente limitadas, elas podem ser abusadas para privilege escalation.
+O AWS IAM Roles Anywhere permite que workloads fora da AWS assumam IAM roles usando certificados X.509. Mas quando as trust policies não estão devidamente limitadas, elas podem ser abusadas para escalonamento de privilégios.
 
-Esta policy não impõe restrições sobre qual trust anchor ou quais atributos do certificado são permitidos. Como resultado, qualquer certificado vinculado a qualquer trust anchor na conta pode ser usado para assumir este role.
+Para entender este ataque, é necessário explicar o que é um trust anchor. Um trust anchor no AWS IAM Roles Anywhere é a entidade raiz de confiança; ele contém o certificado público de uma Certificate Authority (CA) registrada na conta para que a AWS possa validar os certificados X.509 apresentados. Dessa forma, se o certificado do cliente foi emitido por essa CA e o trust anchor estiver ativo, a AWS o reconhece como válido.
+
+Além disso, um profile é a configuração que define quais atributos do certificado X.509 (como CN, OU ou SAN) serão transformados em session tags, e essas tags serão comparadas posteriormente com as condições da trust policy.
+
+Essa policy não possui restrições sobre quais trust anchor ou atributos do certificado são permitidos. Como resultado, qualquer certificado vinculado a qualquer trust anchor na conta pode ser usado para assumir esse role.
 ```json
 {
 "Version": "2012-10-17",
@@ -108,9 +112,9 @@ Esta policy não impõe restrições sobre qual trust anchor ou quais atributos
 }
 
 ```
-Para privesc, o `aws_signing_helper` é necessário de https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
+Para privesc, o `aws_signing_helper` é necessário a partir de https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
 
-Então, usando um certificado válido, o atacante pode realizar pivot para a role de maior privilégio
+Então, usando um certificado válido, o atacante pode pivotar para o role de maior privilégio.
 ```bash
 aws_signing_helper credential-process \
 --certificate readonly.pem \
@@ -119,9 +123,9 @@ aws_signing_helper credential-process \
 --profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
 --role-arn arn:aws:iam::123456789012:role/Admin
 ```
-A âncora de confiança valida que o certificado do cliente `readonly.pem` provém da sua CA autorizada; quando a âncora de confiança foi criada o certificado público da CA foi incluído (e agora é usado para validar `readonly.pem`). Dentro de `readonly.pem` está a chave pública, que a AWS usa para verificar que a assinatura foi feita com a sua chave privada correspondente `readonly.key`.
+A âncora de confiança valida que o certificado `readonly.pem` do cliente vem da sua CA autorizada, e dentro desse certificado `readonly.pem` está a chave pública que a AWS usa para verificar que a assinatura foi feita com a sua chave privada correspondente `readonly.key`.
 
-O certificado também comprova identidade e fornece atributos (como CN ou OU) que o perfil `default` transforma em tags, que a política de confiança da role pode usar para decidir se autoriza o acesso. Se não houver condições na política de confiança, essas tags são ignoradas e qualquer pessoa com um certificado válido é autorizada.
+O certificado também fornece atributos (como CN ou OU) que o perfil `default` transforma em tags, que a política de confiança da role pode usar para decidir se autoriza o acesso. Se não houver condições na política de confiança, essas tags não têm utilidade, e o acesso é concedido a qualquer pessoa com um certificado válido.
 
 Para que este ataque seja possível, tanto a âncora de confiança quanto o perfil `default` devem estar ativos.