diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
index 6ab5ea727..036437fa1 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
@@ -1,23 +1,23 @@
-# AWS - STS 后期利用
+# AWS - STS Post Exploitation
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## STS
 
-更多信息：
+For more information:
 
 {{#ref}}
 ../aws-services/aws-iam-enum.md
 {{#endref}}
 
-### 从 IAM 凭证到控制台
+### 从 IAM 凭证 到 控制台
 
-如果您成功获取了一些 IAM 凭证，您可能会对使用以下工具**访问网络控制台**感兴趣。\
-请注意，用户/角色必须具有权限 **`sts:GetFederationToken`**。
+如果你已获取到一些 IAM 凭证，可能想使用以下工具**访问网页控制台**。\
+注意，该用户/角色必须拥有权限 **`sts:GetFederationToken`**。
 
 #### 自定义脚本
 
-以下脚本将使用默认配置文件和默认 AWS 位置（非政府和非中国）为您提供一个可以用于登录网络控制台的签名 URL：
+下面的脚本将使用默认 profile 和默认的 AWS 区域（not gov and not cn）为你生成一个签名 URL，可用于登录网页控制台：
 ```bash
 # Get federated creds (you must indicate a policy or they won't have any perms)
 ## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
@@ -55,7 +55,7 @@ echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.co
 ```
 #### aws_consoler
 
-您可以使用 [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) **生成一个网络控制台链接**。
+你可以使用 [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) **生成一个 web 控制台链接**。
 ```bash
 cd /tmp
 python3 -m venv env
@@ -64,22 +64,22 @@ pip install aws-consoler
 aws_consoler [params...] #This will generate a link to login into the console
 ```
 > [!WARNING]
-> 确保 IAM 用户具有 `sts:GetFederationToken` 权限，或提供一个角色以进行假设。
+> 确保 IAM 用户具有 `sts:GetFederationToken` 权限，或提供一个可用于假设的角色。
 
 #### aws-vault
 
-[**aws-vault**](https://github.com/99designs/aws-vault) 是一个在开发环境中安全存储和访问 AWS 凭证的工具。
+[**aws-vault**](https://github.com/99designs/aws-vault) 是一个用于在开发环境中安全存储和访问 AWS 凭证的工具。
 ```bash
 aws-vault list
 aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
 aws-vault login jonsmith # Open a browser logged as jonsmith
 ```
 > [!NOTE]
-> 您还可以使用 **aws-vault** 来获取 **浏览器控制台会话**
+> 你也可以使用 **aws-vault** 获取一个 **浏览器控制台会话**
 
-### **通过 Python 绕过 User-Agent 限制**
+### **从 Python 绕过 User-Agent 限制**
 
-如果存在 **基于用户代理执行某些操作的限制**（例如，基于用户代理限制使用 python boto3 库），可以使用前面提到的技术 **通过浏览器连接到 web 控制台**，或者您可以直接 **通过以下方式修改 boto3 用户代理**：
+如果存在 **基于所使用的 User-Agent 对执行某些操作的限制**（例如基于 User-Agent 限制使用 python boto3 库），可以使用前面提到的技术**通过浏览器连接到 web 控制台**，或者你可以直接**修改 boto3 的 User-Agent**，方法如下：
 ```bash
 # Shared by ex16x41
 # Create a client
@@ -92,4 +92,14 @@ client.meta.events.register( 'before-call.secretsmanager.GetSecretValue', lambda
 # Perform the action
 response = client.get_secret_value(SecretId="flag_secret") print(response['SecretString'])
 ```
+### **`sts:GetFederationToken`**
+
+拥有此权限可以为执行该操作的用户创建一个联合身份，但该联合身份的权限被限制为该用户已有的权限。
+```bash
+aws sts get-federation-token --name <username>
+```
+sts:GetFederationToken 返回的 token 属于调用用户的联邦身份，但权限受限。即使该用户具有管理员权限，某些操作（例如列出 IAM users 或附加 policies）也无法通过该联邦 token 执行。
+
+此外，这种方法也更具隐蔽性，因为联邦用户不会出现在 AWS Portal 中，只能通过 CloudTrail logs 或监控工具观察到。
+
 {{#include ../../../banners/hacktricks-training.md}}
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 bab744822..6ff63c3fc 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`
 
-每个角色都是通过**角色信任策略**创建的，该策略指示**谁可以假设创建的角色**。如果来自**同一账户**的角色表示某个账户可以假设它，这意味着该账户将能够访问该角色（并可能进行**权限提升**）。
+每个 role 都会创建一个 **role trust policy**，该策略指明 **谁可以 assume 所创建的 role**。如果一个来自 **same account** 的 role 指定某个 account 可以 assume 它，意味着该 account 将能够访问该 role（并可能进行 **privesc**）。
 
-例如，以下角色信任策略指示任何人都可以假设它，因此**任何用户都将能够进行权限提升**到与该角色相关的权限。
+例如，下面的 role trust policy 表明任何人都可以 assume 它，因此 **any user will be able to privesc** 到与该 role 关联的权限。
 ```json
 {
 "Version": "2012-10-17",
@@ -23,39 +23,20 @@
 ]
 }
 ```
-您可以模拟一个正在运行的角色：
+您可以模拟正在运行的角色：
 ```bash
 aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
 ```
-**潜在影响：** 提权到该角色。
+**Potential Impact:** Privesc 到该角色。
 
 > [!CAUTION]
-> 请注意，在这种情况下，权限 `sts:AssumeRole` 需要在 **被滥用的角色中指明**，而不是在攻击者的策略中。\
-> 除此之外，为了 **从不同账户假设角色**，攻击者账户 **还需要** 对该角色拥有 **`sts:AssumeRole`** 权限。
+> 注意在这种情况下，权限 `sts:AssumeRole` 需要在**要滥用的角色中被指明**，而不是在属于攻击者的策略中。\
+> 除非有一个例外，为了**假设来自不同账户的角色**，攻击者账户**还需要**对该角色拥有 **`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 认证的用户模拟该角色的权限。**
+具有此角色的信任策略会授予**通过 SAML 验证的用户冒充该角色的访问权限。**
 
 具有此权限的信任策略示例如下：
 ```json
@@ -78,36 +59,36 @@ aws sts get-federation-token --name <username>
 ]
 }
 ```
-要生成凭证以模拟角色，您可以使用类似以下内容：
+要生成用于模拟该角色的凭证，通常可以使用类似如下的命令：
 ```bash
 aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
 ```
-但是 **providers** 可能有他们 **自己的工具** 来简化这个过程，比如 [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
 ```
-**潜在影响：** 提权到角色。
+**潜在影响：** Privesc 到该 role。
 
 ### `sts:AssumeRoleWithWebIdentity`
 
-此权限允许为**已在移动、Web 应用程序、EKS...中经过身份验证的用户**获取一组临时安全凭证，使用网络身份提供者。[在这里了解更多。](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+此权限允许通过 web identity provider 为在 **移动设备、web 应用、EKS... 中已完成认证的用户** 获取一组临时安全凭证。 [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
 
-例如，如果**EKS 服务账户**应该能够**模拟 IAM 角色**，它将在**`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`**中拥有一个令牌，并可以**假设该角色并获取凭证**，执行类似以下操作：
+例如，如果一个 **EKS service account** 应该能够 **impersonate an IAM role**，它会在 **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** 中有一个令牌，并且可以通过类似如下的方式 **assume the role and get credentials**：
 ```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
 ```
-### 联邦滥用
+### 联合身份滥用
 
 {{#ref}}
 ../aws-basic-information/aws-federation-abuse.md
 {{#endref}}
 
-### IAM Roles Anywhere 权限提升
+### IAM Roles Anywhere Privesc
 
-AWS IAM RolesAnywhere 允许 AWS 以外的工作负载使用 X.509 证书来承担 IAM 角色。但是，当信任策略没有正确范围时，它们可能会被滥用以进行权限提升。
+AWS IAM RolesAnywhere 允许位于 AWS 之外的工作负载使用 X.509 证书来 assume IAM roles。但当 trust policies 未被正确限定时，它们可能被滥用以实现 privilege escalation。
 
-该策略缺乏对允许的信任锚或证书属性的限制。因此，任何与账户中的任何信任锚相关的证书都可以用来承担此角色。
+该 policy 缺乏对允许的 trust anchor 或 certificate attributes 的限制。因此，任何绑定到账户中任意 trust anchor 的证书都可以用来 assume this role。
 ```json
 {
 "Version": "2012-10-17",
@@ -127,9 +108,9 @@ AWS IAM RolesAnywhere 允许 AWS 以外的工作负载使用 X.509 证书来承
 }
 
 ```
-要进行权限提升，`aws_signing_helper` 是必需的，来自 https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
+要进行 privesc，需要从 https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html 获取 `aws_signing_helper`
 
-然后，使用有效的证书，攻击者可以转向更高权限的角色。
+然后，使用有效的证书，attacker 可以 pivot 到更高权限的角色。
 ```bash
 aws_signing_helper credential-process \
 --certificate readonly.pem \
@@ -138,7 +119,13 @@ 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，在创建信任锚时包含了该 CA 的公钥证书（现在用于验证 `readonly.pem`）。`readonly.pem` 内包含公钥，AWS 使用它来验证签名是否由对应的私钥 `readonly.key` 所生成。
+
+该证书还证明了身份，并提供属性（例如 CN 或 OU），`default` 配置文件将这些属性转换为标签（tags），角色的信任策略可以使用这些标签来决定是否授权访问；如果信任策略中没有条件，则这些标签会被忽略，任何拥有有效证书的人都将被允许通过。
+
+要使此攻击成为可能，信任锚和 `default` 配置文件都必须处于启用状态。
+
+### 参考资料
 
 - [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)