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 644b4cc71..31f731c94 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`
 
-हर भूमिका एक **भूमिका ट्रस्ट नीति** के साथ बनाई जाती है, यह नीति **यह दर्शाती है कि कौन बनाई गई भूमिका को ग्रहण कर सकता है**। यदि **एक ही खाते** से एक भूमिका कहती है कि एक खाता इसे ग्रहण कर सकता है, तो इसका मतलब है कि खाता भूमिका तक पहुँच प्राप्त कर सकेगा (और संभावित रूप से **privesc** कर सकेगा)।
+प्रत्येक role को एक **role trust policy** के साथ बनाया जाता है, यह policy बताती है कि **कौन बनाए गए role को assume कर सकता है**। यदि किसी role में उसी खाते के (**same account**) कहा गया है कि कोई account उसे assume कर सकता है, तो इसका मतलब है कि वह account role तक पहुंच सकेगा (और संभावित रूप से **privesc**)।
 
-उदाहरण के लिए, निम्नलिखित भूमिका ट्रस्ट नीति यह दर्शाती है कि कोई भी इसे ग्रहण कर सकता है, इसलिए **कोई भी उपयोगकर्ता उस भूमिका से संबंधित अनुमतियों तक privesc कर सकेगा**।
+उदाहरण के लिए, निम्न role trust policy दर्शाती है कि कोई भी इसे assume कर सकता है, इसलिए **कोई भी user उस role से जुड़ी permissions पर privesc कर पाएगा**।
 ```json
 {
 "Version": "2012-10-17",
@@ -23,41 +23,21 @@
 ]
 }
 ```
-आप एक भूमिका का अनुकरण कर सकते हैं:
+आप निम्नलिखित चलाकर एक role impersonate कर सकते हैं:
 ```bash
 aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
 ```
-**संभावित प्रभाव:** भूमिका के लिए प्रिवेस्क।
+**संभावित प्रभाव:** role तक Privesc।
 
 > [!CAUTION]
-> ध्यान दें कि इस मामले में अनुमति `sts:AssumeRole` को **दुरुपयोग के लिए भूमिका में इंगित किया जाना चाहिए** और हमलावर की नीति में नहीं।\
-> एक अपवाद के साथ, **किसी अन्य खाते से भूमिका को मान लेना** के लिए हमलावर खाते को **भी** भूमिका पर **`sts:AssumeRole`** होना चाहिए।
+> ध्यान दें कि इस मामले में permission `sts:AssumeRole` को **उस role में संकेतित होना चाहिए जिसे abuse किया जाना है** और attacker की किसी policy में नहीं।\
+> एक अपवाद को छोड़कर, किसी अलग account से **role को assume करने के लिए** attacker account **को भी** उस role पर **`sts:AssumeRole`** होना आवश्यक है।
 
-### **`sts:GetFederationToken`**
-
-इस अनुमति के साथ किसी भी उपयोगकर्ता की नकल करने के लिए क्रेडेंशियल्स उत्पन्न करना संभव है:
-```bash
-aws sts get-federation-token --name <username>
-```
-यह अनुमति इस तरह से सुरक्षित रूप से दी जा सकती है कि अन्य उपयोगकर्ताओं की नकल करने का अधिकार न दिया जाए:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "VisualEditor0",
-"Effect": "Allow",
-"Action": "sts:GetFederationToken",
-"Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}"
-}
-]
-}
-```
 ### `sts:AssumeRoleWithSAML`
 
-इस भूमिका के साथ एक ट्रस्ट नीति **SAML के माध्यम से प्रमाणित उपयोगकर्ताओं को भूमिका का अनुकरण करने की अनुमति देती है।**
+एक trust policy जो इस role के लिए हो, वह **SAML के माध्यम से authenticated users को role का impersonate करने की access देती है।**
 
-इस अनुमति के साथ एक ट्रस्ट नीति का उदाहरण है:
+An example of a trust policy with this permission is:
 ```json
 {
 "Version": "2012-10-17",
@@ -78,21 +58,21 @@ aws sts get-federation-token --name <username>
 ]
 }
 ```
-क्रेडेंशियल्स उत्पन्न करने के लिए ताकि सामान्य रूप से भूमिका का अनुकरण किया जा सके, आप कुछ इस तरह का उपयोग कर सकते हैं:
+आम तौर पर role की नकल करने के लिए credentials जनरेट करने हेतु आप कुछ इस तरह उपयोग कर सकते हैं:
 ```bash
 aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
 ```
-लेकिन **प्रदाताओं** के पास इसे आसान बनाने के लिए **अपने उपकरण** हो सकते हैं, जैसे [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
+लेकिन **प्रदाता** के पास इसे आसान बनाने के लिए अपने **खुद के टूल** हो सकते हैं, जैसे [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
 ```
-**संभावित प्रभाव:** भूमिका के लिए प्रिवेस्क।
+**संभावित प्रभाव:** role पर Privesc।
 
 ### `sts:AssumeRoleWithWebIdentity`
 
-यह अनुमति उन **उपयोगकर्ताओं** के लिए अस्थायी सुरक्षा क्रेडेंशियल्स प्राप्त करने की अनुमति देती है जो एक वेब पहचान प्रदाता के साथ मोबाइल, वेब एप्लिकेशन, EKS... में प्रमाणित किए गए हैं। [यहाँ और जानें।](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+यह अनुमति एक वेब identity provider के साथ **mobile, web application, EKS... में प्रमाणीकृत किए गए उपयोगकर्ताओं** के लिए अस्थायी security credentials का एक सेट प्राप्त करने की अनुमति देती है। [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
 
-उदाहरण के लिए, यदि एक **EKS सेवा खाता** को **IAM भूमिका का अनुकरण** करने में सक्षम होना चाहिए, तो इसके पास **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** में एक टोकन होगा और यह **भूमिका को ग्रहण कर सकता है और क्रेडेंशियल्स प्राप्त कर सकता है** कुछ इस तरह:
+For example, if an **EKS service account** should be able to **impersonate an IAM role**, it will have a token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** and can **assume the role and get credentials** doing something like:
 ```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
@@ -105,9 +85,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
 
 ### IAM Roles Anywhere Privesc
 
-AWS IAM RolesAnywhere बाहरी कार्यभारों को X.509 प्रमाणपत्रों का उपयोग करके IAM भूमिकाएँ ग्रहण करने की अनुमति देता है। लेकिन जब विश्वास नीतियाँ सही तरीके से परिभाषित नहीं होती हैं, तो उनका दुरुपयोग किया जा सकता है।
+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.
 
-इस नीति में यह निर्धारित करने के लिए कोई प्रतिबंध नहीं है कि कौन सा विश्वास एंकर या प्रमाणपत्र विशेषताएँ अनुमति प्राप्त हैं। परिणामस्वरूप, खाते में किसी भी विश्वास एंकर से जुड़े किसी भी प्रमाणपत्र का उपयोग इस भूमिका को ग्रहण करने के लिए किया जा सकता है।
+To understand this attack, it is necessary to explain what a trust anchor is. A trust anchor in AWS IAM Roles Anywhere is the root of trust entity, it contains the public certificate of a Certificate Authority (CA) that is registered in the account so that AWS can validate the presented X.509 certificates. In this way, if the client certificate was issued by that CA and the trust anchor is active, AWS recognizes it as valid.
+
+In addition, a profile is the configuration that defines which attributes of the X.509 certificate (such as CN, OU, or SAN) will be transformed into session tags, and these tags will later be compared against the conditions of the trust policy.
+
+This policy lacks restrictions on which trust anchor or certificate attributes are allowed. As a result, any certificate tied to any trust anchor in the account can be used to assume this role.
 ```json
 {
 "Version": "2012-10-17",
@@ -127,9 +111,9 @@ AWS IAM RolesAnywhere बाहरी कार्यभारों को X.50
 }
 
 ```
-प्रिवेस्क के लिए, `aws_signing_helper` की आवश्यकता है https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html से
+privesc के लिए `aws_signing_helper` https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html से आवश्यक है।
 
-फिर एक मान्य प्रमाणपत्र का उपयोग करके, हमलावर उच्च विशेषाधिकार भूमिका में प्रवेश कर सकता है
+फिर मान्य प्रमाणपत्र का उपयोग करके attacker higher privilege role में pivot कर सकता है।
 ```bash
 aws_signing_helper credential-process \
 --certificate readonly.pem \
@@ -138,6 +122,12 @@ aws_signing_helper credential-process \
 --profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
 --role-arn arn:aws:iam::123456789012:role/Admin
 ```
+ट्रस्ट एंकर सत्यापित करता है कि क्लाइंट का `readonly.pem` प्रमाणपत्र उसके अधिकृत CA से आया है, और इसी `readonly.pem` प्रमाणपत्र में वह सार्वजनिक कुंजी होती है जिसका उपयोग AWS यह सत्यापित करने के लिए करता है कि सिग्नेचर उसके संबंधित प्राइवेट की `readonly.key` से बनाया गया था।
+
+प्रमाणपत्र उन attributes (जैसे CN or OU) को भी प्रदान करता है जिन्हें `default` प्रोफ़ाइल टैग्स में बदल देती है, जिन्हें रोल की ट्रस्ट पॉलिसी यह तय करने के लिए उपयोग कर सकती है कि एक्सेस को अनुमोदित करना है या नहीं। यदि ट्रस्ट पॉलिसी में कोई conditions नहीं हैं, तो वे टैग्स किसी काम के नहीं होते, और किसी भी वैध प्रमाणपत्र वाले को एक्सेस दे दिया जाता है।
+
+इस हमले के संभव होने के लिए, दोनों — ट्रस्ट एंकर और `default` प्रोफ़ाइल — सक्रिय होने चाहिए।
+
 ### संदर्भ
 
 - [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)