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 63f730ee5..ca1b55dca 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`
 
-Elke role word geskep met 'n **role trust policy**, hierdie policy dui aan **wie die geskepte role kan assume**. As 'n role van die **same account** sê dat 'n account dit kan assume, beteken dit dat daardie account toegang tot die role sal hê (en moontlik **privesc**).
+Elke rol word geskep met 'n **rol se vertrouensbeleid**, hierdie beleid dui aan **wie die geskepte rol kan aanneem**. As 'n rol van die **dieselfde rekening** sê dat 'n rekening dit kan aanneem, beteken dit dat daardie rekening toegang tot die rol sal hê (en moontlik **privesc**).
 
-Byvoorbeeld dui die volgende **role trust policy** aan dat enigiemand dit kan assume, daarom sal **any user** in staat wees om te **privesc** na die permissions geassosieer met daardie role.
+Byvoorbeeld, die volgende rol se vertrouensbeleid dui aan dat enigiemand dit kan aanneem, daarom sal **enige gebruiker sal in staat wees om te privesc** tot die toestemmings wat aan daardie rol gekoppel is.
 ```json
 {
 "Version": "2012-10-17",
@@ -23,22 +23,22 @@ Byvoorbeeld dui die volgende **role trust policy** aan dat enigiemand dit kan as
 ]
 }
 ```
-Jy kan 'n rol naboots deur die volgende uit te voer:
+Jy kan 'n rol naboots wat loop:
 ```bash
 aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
 ```
-**Potensiële impak:** Privesc na die rol.
+**Potensiële impak:** Privesc na die role.
 
 > [!CAUTION]
-> Neem kennis dat in hierdie geval die toestemming `sts:AssumeRole` **in die rol wat misbruik word aangedui moet wees** en nie in 'n beleid wat aan die aanvaller behoort nie.\
-> Met een uitsondering, om **'n rol van 'n ander rekening aan te neem** moet die aanvallerrekening **ook** die **`sts:AssumeRole`** oor die rol hê.
+> Let wel dat in hierdie geval die toestemming `sts:AssumeRole` **indicated in the role to abuse** moet wees en nie in 'n beleid wat aan die attacker behoort nie.\
+> Met een uitsondering: om **assume a role from a different account** te kan doen, moet die attacker account **ook** die **`sts:AssumeRole`** oor die role hê.
 
 
 ### `sts:AssumeRoleWithSAML`
 
-'n trust policy met hierdie rol verleen **gebruikers wat via SAML geverifieer is toegang om die rol te verpersoonlik.**
+'n trust policy met hierdie role verleen **users authenticated via SAML access to impersonate the role.**
 
-'n Voorbeeld van 'n trust policy met hierdie toestemming is:
+'n voorbeeld van 'n trust policy met hierdie toestemming is:
 ```json
 {
 "Version": "2012-10-17",
@@ -59,7 +59,7 @@ aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
 ]
 }
 ```
-Om credentials te genereer om die rol te impersonate, kan jy gewoonlik iets soos die volgende gebruik:
+Om credentials te genereer om die rol te imiteer, kan jy gewoonlik iets soos die volgende gebruik:
 ```bash
 aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
 ```
@@ -71,9 +71,9 @@ onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --
 
 ### `sts:AssumeRoleWithWebIdentity`
 
-Hierdie toestemming maak dit moontlik om 'n stel tydelike sekuriteitsgeloofsbriewe te bekom vir **gebruikers who have been authenticated in a mobile, web application, EKS...** met 'n web identity provider. [Lees meer hier.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+Hierdie toestemming laat toe om 'n stel tydelike sekuriteitsbewyse te kry vir **gebruikers wat geverifieer is in 'n mobiele of webtoepassing, EKS...** by 'n web-identity-verskaffer. [Lees meer hier.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
 
-Byvoorbeeld, as 'n **EKS service account** in staat moet wees om **impersonate an IAM role**, sal dit 'n token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** hê en kan dit **assume the role and get credentials** deur iets soos:
+Byvoorbeeld, as 'n **EKS service account** in staat moet wees om **impersonate an IAM role**, sal dit 'n token hê in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** en kan dit **die role aanvaar en inlogbewyse kry** deur iets soos:
 ```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 laat workloads buite AWS toe om IAM roles aan te neem met X.509 certificates. Maar wanneer trust policies nie behoorlik afgebaken is nie, kan dit misbruik word vir privilege escalation.
+AWS IAM RolesAnywhere allows workloads outside AWS to assume IAM roles using X.509 certificates. But when trust policies aren't properly scoped, they can be abused for privilege escalation.
 
-Hierdie policy het geen beperkings op watter trust anchor of certificate attributes toegelaat word nie. As gevolg hiervan kan enige certificate wat aan enige trust anchor in die account gekoppel is, gebruik word om hierdie rol te assume.
+Om hierdie aanval te verstaan, is dit nodig om te verduidelik wat 'n trust anchor is. 'n trust anchor in AWS IAM RolesAnywhere is die wortel-entiteit van vertroue; dit bevat die publieke sertifikaat van 'n Certificate Authority (CA) wat in die rekening geregistreer is sodat AWS die gepresenteerde X.509-sertifikate kan valideer. Op hierdie manier, as die kliëntsertifikaat deur daardie CA uitgereik is en die trust anchor aktief is, erken AWS dit as geldig.
+
+Verder is 'n profile die konfigurasie wat bepaal watter kenmerke van die X.509-sertifikaat (soos CN, OU, or SAN) in session tags omskakel sal word, en hierdie tags sal later vergelyk word teen die voorwaardes van die trust policy.
+
+Hierdie policy het nie beperkings op watter trust anchor of sertifikaatkenmerke toegelaat word nie. Gevolglik kan enige sertifikaat wat aan enige trust anchor in die rekening gekoppel is, gebruik word om hierdie rol aan te neem.
 ```json
 {
 "Version": "2012-10-17",
@@ -108,9 +112,9 @@ Hierdie policy het geen beperkings op watter trust anchor of certificate attribu
 }
 
 ```
-Om privesc te bereik, is die `aws_signing_helper` benodig vanaf https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
+Vir privesc is die `aws_signing_helper` benodig vanaf https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
 
-Dan, deur 'n geldige sertifikaat te gebruik, kan die attacker pivot in die rol met hoër voorregte
+Deur 'n geldige sertifikaat te gebruik, kan die attacker na 'n rol met hoër voorregte pivot.
 ```bash
 aws_signing_helper credential-process \
 --certificate readonly.pem \
@@ -119,11 +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
 ```
-Die vertrouensanker valideer dat die kliëntsertifikaat `readonly.pem` van sy gemagtigde CA kom. Toe die vertrouensanker geskep is, is die CA se publieke sertifikaat ingesluit (en word nou gebruik om `readonly.pem` te valideer). Binne-in `readonly.pem` is die publieke sleutel, wat AWS gebruik om te verifieer dat die handtekening met die ooreenstemmende private sleutel `readonly.key` gemaak is.
+Die trust anchor verifieer dat die kliënt se `readonly.pem`-sertifikaat van sy gemagtigde CA afkomstig is, en binne hierdie `readonly.pem`-sertifikaat is die publieke sleutel wat AWS gebruik om te verifieer dat die handtekening met die ooreenstemmende private sleutel `readonly.key` gemaak is.
 
-Die sertifikaat bewys ook identiteit en verskaf attribuutte (soos CN of OU) wat die `default` profiel omskakel in etikette (tags), wat die rol se vertrouensbeleid kan gebruik om te besluit of toegang gemagtig moet word. As daar geen voorwaardes in die vertrouensbeleid is nie, word daardie etikette geïgnoreer en word enigiemand met 'n geldige sertifikaat toegelaat.
+Die sertifikaat verskaf ook attribuutte (soos CN of OU) wat die `default` profiel in tags omskakel, wat die rol se trust policy kan gebruik om te besluit of toegang gemagtig word. As daar geen toestande in die trust policy is nie, het daardie tags geen nut nie, en word toegang toegestaan aan enigiemand met 'n geldige sertifikaat.
 
-Vir hierdie aanval om moontlik te wees, moet beide die vertrouensanker en die `default` profiel aktief wees.
+Vir hierdie aanval om moontlik te wees, moet beide die trust anchor en die `default` profiel aktief wees.
 
 ### Verwysings