DataDog/pathfinding-labs

GitHub: DataDog/pathfinding-labs

一个模块化的 AWS 多账户攻击路径演练平台,通过在沙箱中部署含故意漏洞的云资源帮助安全团队练习云身份攻击与防御。

Stars: 50 | Forks: 5

pathfinding-labs-3800x1930 (2) **一个用于部署包含故意漏洞的 AWS 配置的模块化平台** ![Labs](https://img.shields.io/badge/Labs-100%2B-blue?style=for-the-badge) [快速开始](#quick-start) • [实验室目录](https://pathfinding.cloud/labs) • [工作原理](#how-it-works) • [安全](#what-gets-deployed) • [贡献](#contributing)
Pathfinding Labs 通过在沙箱环境中部署包含故意漏洞的云资源,帮助安全团队学习如何攻击和防御可利用的身份配置错误。 pathfinding-labs-overview (1) ## 支持哪些类型的实验室? pathfinding-lab-types (2) ## 快速开始 ### 前置条件 - 一个或多个 AWS 账户(仅限演练/沙箱账户——切勿使用生产环境) - AWS CLI 已为每个账户配置了命名的 profile 不知道如何设置?请参阅[设置指南](setup/README.md)——无论你是从单个账户开始,还是已经准备好账户,或者想创建一个完整的多账户 AWS 组织。 ### 安装 plabs ##### 直接安装 需要 Go 1.25+ ``` go install -v github.com/DataDog/pathfinding-labs/cmd/plabs@latest ``` ##### Homebrew ``` brew tap DataDog/pathfinding-labs https://github.com/DataDog/pathfinding-labs brew install DataDog/pathfinding-labs/plabs ``` #### 从 GitHub Releases 下载 ``` OS=$(uname -s | tr '[:upper:]' '[:lower:]') ARCH=$(uname -m | sed 's/x86_64/amd64/') VERSION=$(curl -fsSL https://api.github.com/repos/DataDog/pathfinding-labs/releases/latest | grep '"tag_name"' | cut -d'"' -f4 | tr -d 'v') curl -fsSL "https://github.com/DataDog/pathfinding-labs/releases/download/v${VERSION}/plabs_${VERSION}_${OS}_${ARCH}.tar.gz" | tar -xz plabs sudo mv plabs /usr/local/bin/ ``` #### 从源码构建 ``` git clone https://github.com/DataDog/pathfinding-labs.git cd pathfinding-labs go build -o plabs ./cmd/plabs cp plabs /usr/local/bin/ chmod +x /usr/local/bin/plabs ``` ### 设置 #### 初始化: 下载 terraform,克隆仓库,运行 AWS profile 设置向导 ``` plabs init ``` #### 打开 TUI 仪表板 ``` plabs ``` plabs **在 TUI 中:使用 ↑↓ 浏览实验室,空格键启用/禁用实验室,a 应用更改(部署已启用的实验室,销毁已禁用的实验室)** # 工作原理 **模块化架构**:每个攻击实验室都是一个独立、可独立部署的模块,可通过 `plabs` 启用或禁用。 ``` ┌─────────────────────────────────────────────────────────┐ │ 1. Select labs (plabs TUI or plabs enable) │ │ space to toggle in TUI, or: plabs enable │ ├─────────────────────────────────────────────────────────┤ │ 2. Deploy (plabs apply) │ │ Creates vulnerable resources in your AWS account │ ├─────────────────────────────────────────────────────────┤ │ 3. Test (plabs demo ) │ │ Exploit OR detect with your CSPM │ ├─────────────────────────────────────────────────────────┤ │ 4. Clean Up (plabs disable && │ │ plabs apply) │ └─────────────────────────────────────────────────────────┘ ``` ### 实验室输出 所有实验室都通过分组的 Terraform 输出公开凭证和资源信息。演示脚本会自动读取这些信息——无需手动设置凭证。 ## 配置 所有配置都通过 `plabs` 进行管理。无需直接编辑 Terraform 文件。 ### 配置 AWS Profiles 运行交互式设置向导(推荐): ``` plabs init ``` 或直接设置值(适用于 CI/自动化): ``` plabs config set prod-profile my-prod-profile plabs config set prod-region us-east-1 ``` | 键 | 必填 | 描述 | |-----|----------|-------------| | `prod-profile` | 是 | 生产账户的 AWS CLI profile | | `prod-region` | 是 | 生产账户的 AWS region | | `dev-profile` | 否 | 开发账户 profile(仅限跨账户实验室) | | `dev-region` | 否 | 开发账户 region | | `ops-profile` | 否 | 运维账户 profile(仅限跨账户实验室) | | `ops-region` | 否 | 运维账户 region | **你只需一个 AWS 账户即可使用 Pathfinding Labs 的大部分功能。** 所有单账户实验室都部署到 `prod`。开发和运维仅在跨账户实验室中需要。如果你在配置账户和 profile 时需要帮助,请参阅[设置指南](setup/README.md)。 ### 开发者模式 默认情况下,`plabs` 使用克隆到 `~/.plabs/pathfinding-labs/` 的仓库。如果你正在贡献代码并希望测试本地的 Terraform 更改,请从仓库内部启用开发者模式: ``` # 在你的克隆的 pathfinding-labs 目录内运行 plabs config set dev-mode true # plabs 现在使用本地模块,而不是 ~/.plabs/pathfinding-labs/ plabs config set dev-mode false # revert to the managed copy ``` ### 启用和禁用实验室 **交互式(TUI):** ``` plabs # open the dashboard # ↑↓ 导航,空格切换,a 部署 ``` **CLI:** ``` # 通过 lab ID 启用 plabs enable iam-002-iam-createaccesskey # 一次启用多个 plabs enable iam-002-iam-createaccesskey lambda-001-iam-passrole # 禁用 plabs disable iam-002-iam-createaccesskey ``` ### 部署 ``` plabs apply # shows plan, prompts for confirmation plabs apply -y # skip confirmation plabs plan # preview changes without deploying ``` ## 运行攻击演示 每个实验室都包含一个演示脚本,展示如何利用该漏洞。 **使用 plabs(推荐):** ``` plabs demo iam-002-iam-createaccesskey plabs cleanup iam-002-iam-createaccesskey ``` **直接从实验室目录运行:** ``` cd modules/scenarios/single-account/privesc-one-hop/to-admin/iam-002-iam-createaccesskey ./demo_attack.sh ./cleanup_attack.sh ``` 演示脚本提供: - ✅ 逐步的漏洞利用演练 - ✅ 带有解释的 AWS CLI 命令 - ✅ 权限提升的实时验证 - ✅ 带有颜色区分的清晰输出 - ✅ **自动凭证检索** —— 无需手动设置 AWS profile Screenshot 2026-05-07 at 11 59 10 AM ## 部署内容 准确了解 Pathfinding Labs 在你的账户中创建了什么,有助于你评估风险并合理规划测试环境。 ### IAM 资源 每个实验室都会创建带有故意配置错误的 IAM principals(用户、角色)和策略。**不会修改你账户中的任何现有资源。** 所有创建的资源都使用 `pl-` 前缀,以便于识别和审计。 ### 起始用户 每个配置的环境都会获得一个具有**最低权限**的专用起始用户——这是模拟攻击者的初始立足点: | 用户 | 环境 | |------|-------------| | `pl-pathfinding-starting-user-prod` | 生产环境 | | `pl-pathfinding-starting-user-dev` | 开发环境 | | `pl-pathfinding-starting-user-operations` | 运维环境 | 起始用户仅被授予两项权限: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:GetCallerIdentity", "iam:GetUser" ], "Resource": "*" } ] } ``` ### 清理管理员用户 每个环境还包含一个管理员级别用户,仅供清理脚本用于还原演示制品: - **`pl-admin-user-for-cleanup-scripts`** 该用户拥有广泛的权限。它的存在是为了让清理脚本能够撤销在攻击演示期间所做的更改(例如,删除创建的访问密钥,还原修改的策略)。**这是将你的实验室环境与生产环境隔离的另一个原因。** ### 按实验室类型划分的网络暴露 并非所有实验室都会将资源暴露给互联网: | 类别 | 网络暴露 | |----------|-----------------| | 权限提升(所有跳数) | 无 —— 仅限 IAM,无网络资源 | | CSPM 配置错误 / 有毒组合 | 部分实验室会故意创建公开的 S3 bucket、Lambda 函数 URL 或开放的安全组 | 每个场景的 README 都记录了它创建的内容以及任何面向公众的资源。 ### 费用指南 大多数实验室仅涉及 IAM,不会产生 AWS 费用。部署计算或存储资源(EC2、Lambda、ECS)的实验室在部署期间会产生少量费用。建议:每月设置 10-20 美元的账单警报作为安全保障。 不主动测试时,请销毁实验室: ``` plabs disable && plabs apply # disable a specific scenario plabs destroy # destroy all deployed resources ``` ### 隔离 所有资源仅在你通过 `plabs config` 配置的账户和 region 中创建。清理是完全的——`plabs destroy` 会移除 Pathfinding Labs 创建的所有内容。 ## 资源命名约定 所有资源都遵循一致的命名模式: ``` pl-{resource-description}-{context} Examples: - pl-pathfinding-starting-user-prod - pl-cak-admin (CreateAccessKey Admin) - pl-prod-one-hop-putrolepolicy-role ``` 全局唯一的资源(S3 bucket)包含一个随机后缀: ``` pl-{resource}-{account-id}-{random-6-char} Example: - pl-sensitive-data-954976316246-a3f9x2 ``` ## 实验室分类 Pathfinding Labs 将实验室组织为五个类别: ### **自我提升** Principal 直接修改自身以获取提升的权限,而无需遍历到另一个 principal。这是权限提升最直接的形式,即实体为自身授予额外权限。 **示例:** - `Role → iam:PutRolePolicy (on self) → Admin` - `User → iam:PutUserPolicy (on self) → Admin` - `User → iam:AddUserToGroup → AdminGroup → Admin` - `Role → iam:AttachRolePolicy (on self) → S3 Bucket Access` ### **单跳权限提升** 单个 principal 遍历实验室,其中一个 principal 获取对另一个 principal 权限的访问。这些是 prod 环境中的单账户实验室。 **示例:** - `Role → iam:CreateAccessKey → AdminUser → Admin` - `Role → iam:PassRole + lambda:CreateFunction → AdminRole → Admin` - `Role → lambda:UpdateFunctionCode → Lambda with Admin Role → Admin` - `Role → ssm:SendCommand → EC2 with Admin Role → Admin` ### **多跳权限提升** 通过多个 principal 链接的多个权限提升步骤。这些是 prod 环境中的单账户实验室。 **示例:** - `User → sts:AssumeRole → RoleA → iam:CreateAccessKey → UserB → AssumeRole → AdminRole` - `RoleA → iam:PutRolePolicy → RoleB → AssumeRole → RoleC → Sensitive Bucket` ### **CSPM:配置错误** CSPM 工具应能检测到的单条件安全配置错误。这些是 prod 环境中的单账户实验室。 **示例:** - `EC2 Instance with Admin Role` - 过度宽松的实例 profile - `S3 Bucket (public)` - 可公开访问的存储 - `Security Group (0.0.0.0/0)` - 无限制的网络访问 ### **CSPM:有毒组合** 多种复合的配置错误,共同构成严重的安全风险。这些是 prod 环境中的单账户实验室。 **示例:** - `Lambda Function (publicly accessible) + Admin Role` - `EC2 Instance (publicly accessible) + Critical CVE + Admin Role` - `S3 Bucket (public) + Sensitive Data + No Encryption` ### **跨账户权限提升** 跨越多个 AWS 账户(dev、ops、prod)的权限提升路径。这些实验室演示了在一个账户中的沦陷如何导致对另一个账户的访问。 **示例:** - `Dev:User → AssumeRole → Prod:Role → Admin` - `Dev:Role → Lambda:InvokeFunction → Prod:Lambda → Extract Credentials → Prod:Admin` - `Ops:User → AssumeRole → Prod:Role → S3:SensitiveBucket` ## 架构 ### 目录结构 ``` pathfinding-labs/ ├── modules/ │ ├── environments/ # Base infrastructure (always deployed) │ │ ├── prod/ # Production environment base resources │ │ ├── dev/ # Development environment base resources │ │ └── operations/ # Operations environment base resources │ │ │ └── scenarios/ # Attack labs (opt-in via flags) │ ├── single-account/ │ │ ├── privesc-self-escalation/ │ │ │ ├── to-admin/ # Principal modifies itself to gain admin │ │ │ └── to-bucket/ # Principal modifies itself for S3 access │ │ ├── privesc-one-hop/ │ │ │ ├── to-admin/ # Single principal traversal to admin │ │ │ └── to-bucket/ # Single principal traversal to S3 access │ │ ├── privesc-multi-hop/ │ │ │ ├── to-admin/ # Multiple principal traversals to admin │ │ │ └── to-bucket/ # Multiple principal traversals to S3 access │ │ ├── cspm-misconfig/ # Single-condition security misconfigurations │ │ └── cspm-toxic-combo/ # Multiple compounding misconfigurations │ ├── tool-testing/ # Edge cases for testing detection engines │ ├── ctf/ # Capture-the-flag challenges (no demo scripts) │ ├── attack-simulation/ # Recreations of real-world cloud breaches │ └── cross-account/ │ ├── dev-to-prod/ # Dev → Prod attack paths │ │ ├── one-hop/ # Single-hop cross-account escalation │ │ └── multi-hop/ # Multi-hop cross-account escalation │ └── ops-to-prod/ # Ops → Prod attack paths │ └── one-hop/ # Single-hop cross-account escalation │ ├── main.tf # Root module with conditional instantiation ├── variables.tf # Boolean flags for each scenario ├── outputs.tf # Credential outputs for testing └── terraform.tfvars # Your configuration (gitignored) ``` ### 模块结构 每个实验室都遵循标准结构: ``` scenario-name/ ├── main.tf # Terraform resources ├── variables.tf # Input variables ├── outputs.tf # Output values ├── README.md # Documentation with mermaid diagrams ├── demo_attack.sh # Exploitation demonstration └── cleanup_attack.sh # Artifact cleanup script ``` ## CSPM 检测示例 每个实验室都记录了配置正确的 CSPM 应检测到的内容: ### 示例:iam-createaccesskey 场景 **预期的 CSPM 警报:** - ⚠️ IAM role 可以为特权用户创建访问密钥 - ⚠️ 检测到权限提升路径 - ⚠️ Role 拥有对管理员用户的权限 - ⚠️ 存在凭证被盗风险 **MITRE ATT&CK 映射:** - **战术**:权限提升、持久化 - **技术**:T1098.001 - 账户操纵:额外的云凭证 ## 贡献 我们欢迎你的贡献!要添加新场景: 1. 按照标准结构**创建实验室目录** 2. 使用正确的 provider 配置**实现资源** 3. **编写文档**,包括 mermaid 图表和 CSPM 检测说明 4. **创建演示脚本**,展示漏洞利用技术 5. 使用条件实例化**添加到 main.tf** 6. **向 variables.tf 添加布尔变量** 7. **更新 terraform.tfvars.example** 8. 在隔离的 AWS 账户中**进行全面测试** —— 启用开发者模式(`plabs config set dev-mode true`)以使用你的本地副本,然后执行 `plabs enable && plabs apply` 9. **提交 pull request** 并附带清晰的描述 有关详细说明,请参阅我们的[贡献指南](CONTRIBUTING.md)。 ## 重要警告 ### **仅在演练/沙箱账户中使用** - ❌ **切勿**部署到生产 AWS 账户 - ❌ **切勿**部署到包含真实客户数据的账户 - ❌ **切勿**部署到包含生产工作负载的账户 - ✅ **务必**使用隔离的演练/沙箱账户 - ✅ **务必**在使用完毕后销毁资源 - ✅ **务必**监控成本并设置账单警报 ### 安全最佳实践 1. **使用 SCP** 防止意外部署到生产环境 2. **设置账单警报** 以及时发现意外费用 3. **使用单独的 AWS Organizations** 进行测试 4. 在启用前**审查每个场景** 5. 为了合规和审计目的,**记录你的测试过程** ## 附加资源 - [IAM Vulnerable 项目](https://github.com/bishopfox/iam-vulnerable) - 单账户路径的灵感来源 - [MITRE ATT&CK 云矩阵](https://attack.mitre.org/matrices/enterprise/cloud/) - Datadog 提供的 [Stratus Red Team](https://github.com/DataDog/stratus-red-team) ## 许可证 本项目基于 [Apache License 2.0](LICENSE) 授权。
标签:AWS, DPI, Go语言, Modbus, 安全靶场, 攻击路径, 日志审计, 程序破解, 红队训练, 身份与访问管理