文章总结： 本文介绍Datadog发布的pathfinding.cloud知识库，收录超60种AWSIAM权限提升路径。文章指出开源工具存在42%检测缺口，详细解析路径分类与利用前提。核心建议是安全团队利用该库检查工具覆盖率，修复盲区，并鼓励研究人员贡献新路径以完善防御。 综合评分： 88 文章分类： 云安全,渗透测试,漏洞分析,红队
AWS云权限提升路径大全
Dubito
云原生安全指北
2025年12月19日 08:35 江苏
注：本文翻译自 Datadog 的文章《Introducing Pathfinding.cloud》[1]，可点击文末“阅读原文”按钮查看英文原文。
全文如下：
一、引言
今天我们正式发布 pathfinding.cloud[2]，这是一个全面的知识库，记录了 AWS 中允许权限提升的 IAM 权限和权限集。该库中的每一条路径都明确指出了其可被利用所需的前提条件，并包含攻击可视化图表、推荐的修复步骤以及其他支持性详细信息。
权限提升是 AWS 环境中的一个重大隐患。即使某个身份本身没有直接的管理员访问权限，但其已拥有的权限可能允许它获取该权限。我们将这种情况称为具备提升自身权限的能力，即权限提升。攻击者[3] 在获得对 AWS 账户的初始访问权限后，通常会利用[4]这些提升路径，以扩展其可用的权限。
为了降低这种风险，大多数组织在为工作负载和人类用户分配权限时，都遵循最小权限原则。他们不会在 AWS 账户中广泛授予管理员级别的权限，而是将这些权限限制在一小部分身份上，因为攻击者只要攻破其中任何一个身份，就能获得对整个环境的控制。
该知识库收录了超过 60 条独特的路径，而我们的工作仍在继续。我们仍需添加其他先前已有记录的路径，并且社区每年都会发现和分享新的路径。以下是路径列表的预览。
权限提升路径库
二、为什么我们应该关注 IAM 权限提升？
2018 年，Spencer Gietzen[5] 概述了 AWS 中 21 种允许此类权限提升的 IAM 权限和权限集。每一种都代表了一种方式，使得一个 AWS 主体（IAM 用户或 IAM 角色）能够直接提升自身权限，或者获取对另一个 AWS 主体的访问权限。在下文中，我将把这些权限或权限组合称为 PrivEsc 路径或 路径。在最坏的情况下，这些路径会允许一个非管理员主体获得具有管理员级别访问权限的主体的访问权。这是一个严重的问题，因为这几乎总是出乎意料的。
有时，这些路径允许一个非管理员主体获取另一个非管理员主体的访问权限。您可能认为这没什么大不了的。但是，如果第二个主体能访问第一个主体无法访问的敏感数据，那么这条路径仍然非常重要且具有影响力。
对许多从业者而言，眼见为实。2019年，Bishop Fox 的 Gerben Kleijn 撰写了一篇文章[6]，展示了如何手动利用 Spencer 原始研究中那21条 AWS 权限提升路径。2021年，我创建了 IAM Vulnerable[7]，以便渗透测试人员和安全从业者可以在他们自己的沙箱环境中部署那最初的21条路径，并练习如何利用它们。在那项研究过程中，我又向 IAM Vulnerable 添加了10条新路径，使其支持的路径总数达到31条。这些新路径大多是在查看了 pmapper[8] 的源代码后添加的，这是一个由 Erik Steringer 编写的开源工具，用于尝试检测 AWS 账户中的这些权限提升路径。
说到开源工具，在同样回溯到2021年的后续研究[9]中，我评估了四个开源的 IAM PrivEsc 评估工具，以查看它们各自能识别多少条路径。它们的检测范围在当时 IAM Vulnerable 支持的31条路径中，从14条到22条不等。但问题在于：存在的路径远不止31条！
三、权限提升文档和检测覆盖率的差距
多年来，我注意到新的 AWS 权限提升路径仍在被提出和记录。然而，该领域的开源评估工具却未能跟上这些新增内容，原因可能是项目不再维护，或者开源工具的作者并不总是了解最新的研究。我注意到的另一点是，有些路径在理论上为一些人所知，因为它们与已有记录的路径非常相似，但这些路径本身却没有被记录下来。一个例子是已有记录的路径：iam:PassRole + cloudformation:CreateStack。然而，以下使用 StackSet 而非 Stack 的变体虽极为相似，却此前未被记录：iam:PassRole + cloudformation:CreateStackSet + cloudformation:CreateStackInstances。
结果就是，我们的开源评估工具漏掉了许多允许权限提升的路径。在目前 pathfinding.cloud 知识库收录的65条路径中，有27条（即42%）不被我们评估的任何开源工具所检测。
开源工具检测缺口
这在实践中意味着，即使是那些已经将 IAM 策略扫描以查找权限提升路径投入运营的组织，或者那些执行自动化或半自动化权限提升识别活动的组织，其环境中仍可能存在未被发现的路径。而这些路径是攻击者可以利用的！
那么，我们如何才能弥补工具覆盖范围、普遍认知和实际情况之间的这种差异呢？
四、记录权限提升路径的结构化方法
我采取的方法是，使用标准化的模式开始记录所有已知的权限提升路径，重点在于通过唯一标识符和唯一权限组合来消除歧义。每条路径还包含明确的解释步骤，以便工具作者在决定将其纳入工具之前，能够复现该攻击方法。相关数据是完全开源的，因此任何人都可以通过添加单个 YAML 文件来贡献额外的路径。
说到这里，如果您还没看过的话，我鼓励您前往 https://pathfinding.cloud[2] 亲自查看一下。以下是 apprunner-001[10] 路径的示例展示：
路径详情视图
对于那些喜欢了解幕后故事的人，我将分享我做出的一些决定及其背后的原因。
五、权限提升技术的剖析
5.1 攻击分类
我最初的决定之一是将权限提升路径分为五种不同的类型。
攻击分类
自我提升 涉及一个主体直接修改其自身的权限（例如，对附加策略执行 iam:CreatePolicyVersion）。
主体访问 是指你获得了对另一个主体的访问权限，而不依赖中间计算组件（如 EC2 实例或 Lambda）。一个常见的例子是对另一个用户执行 iam:CreateAccessKey。
新建 PassRole 路径指所有包含 iam:PassRole 的路径。它们值得单独归为一类，因为它们遵循一个一致的模式：将一个高权限角色传递给一个新创建的、能执行代码或命令的 AWS 资源。无论是 EC2、Lambda、Glue 还是 Bedrock，其利用方式在结构上都是相同的。
现有 PassRole 路径涉及修改现有资源（例如 lambda:UpdateFunctionCode）以获得对新主体的访问权限。这些路径需要单独分类，因为它们虽然不需要利用 iam:PassRole 权限，但要求存在特定类型的资源，并且该资源关联了一个具有成功利用所需适当权限的角色。
凭据访问 涉及使用读取级别的权限来访问可能包含或不包含凭据的资源。我尚未添加任何此类路径，因为我仍不确定它是否应归于此地。此类的一个例子是 lambda:ListFunctions。如果你拥有此权限，通常可以在 Lambda 环境变量中找到额外的凭据。如果你对这些路径是应该放在上述类别旁边，还是值得单独成为一个章节有任何看法，请告诉我你的想法！
5.2 权限：必需权限与附加权限
这部分和下一部分对我来说可能是最重要的两点。关于权限，我将其分为两类：required（实施攻击所需的最低权限）和additional（有助于侦查）。例如，iam:PassRole 是将角色传递给 EC2 所必需的，而 iam:ListRoles 只是帮助你发现可用角色。关键在于，攻击者可能会从另一个被入侵的主体获得这些有用的权限，这就是我们不将读取权限视为必需的原因。
5.3 先决条件
多年来，我曾向许多渗透测试人员和安全从业者讲授 AWS 权限提升，而这一点对大多数人来说是最难掌握的概念之一。在某些情况下，即使你拥有必需的权限，也可能缺少发动攻击所需的其他一些先决条件。
让我们以 lambda:UpdateFunctionCode 权限为例并进行分析。假设你对所有 Lambda 函数都拥有此权限。
- • 如果不存在任何 Lambda 函数，则此攻击无法实施。
- • 如果存在 Lambda 函数，但它们都没有在运行中关联 IAM 角色，你可以执行攻击但不会获得任何新的 IAM 权限。
- • 即使 Lambda 函数确实附加了 IAM 角色，但如果没有任何 Lambda 函数是使用管理员权限运行的，那么也无法直接利用此权限提升方法获得管理员访问权限。
- • 最后，如果你只有
lambda:UpdateFunctionCode权限，而没有其他允许你调用该函数的权限，那么你只能更新代码，但代码永远不会执行。为此权限提升方法生效，你需要有东西来触发函数的执行。有时已经有东西在定期调用该函数，但其他时候则并非如此。
因此，对于 pathfinding.cloud 中的每一条路径，我们都包含了获得管理员访问权限所需的先决条件，以及仅仅获得额外 IAM 权限所需的先决条件。
六、路径关系（变体）
谈到先决条件和路径，让我们继续思考 lambda:UpdateFunctionCode 这个权限。正如上文所述，如果你只有此权限，并且没有任何东西调用该函数，那么这条路径不会导致权限提升。但如果你同时拥有 lambda:UpdateFunctionCode 和 lambda:InvokeFunction，情况就不同了。拥有这项额外的权限就移除了“必须有其他东西调用函数此路径才能生效”这一先决条件。凭借这些权限，你自己就可以成为调用函数的那个人！
我决定将这些变体作为具有唯一 ID 的独立权限提升路径来添加，但将它们归类为主要路径的变体，以便区分。这样做的原因是，一些工具已经能够检测部分变体，而其他工具则不能。通过为每个变体提供唯一的标识符，并展示各自不同的利用步骤，我希望能让工具开发者更容易地检测所有这些变体。
6.1 学习环境与检测覆盖率
模式中的两个字段直接解决了“认知差距”问题：learningEnvironments 和 detectionTools。
对于每条路径，我都会记录哪些开源和商业实验室环境允许你进行实践。这有两个目的：渗透测试人员可以磨练他们的利用技能，而安全团队可以验证他们的检测工具是否能真正发现它。
detectionTools 字段精确地显示了哪些开源工具检测到每条路径，并尽可能直接链接到源代码的行号。当一个工具未被列出时，这就是一个明显的缺口。这种透明度让安全团队了解他们遗漏了什么，并帮助工具的维护者看到需要在哪里增加覆盖。
6.2 唯一标识符与机器可读模式
每条路径都有一个唯一的 ID，例如 iam-001 或 ec2-003。对于 PassRole 路径，我使用被利用的服务（而非 IAM）来命名，因此 iam:PassRole + lambda:CreateFunction 就变成了 lambda-001。这使得涉及的服务一目了然。
整个模式[11]定义了一个机器可读的 YAML 文件，每条路径都使用该格式，它们会被统一导出到一个单一的 paths.json[12] 文件，为网站提供数据支持。以下是其中最常被利用的权限提升路径之一，ec2-001: iam:PassRole + ec2:RunInstances[13] 的 YAML 格式概览：
id: ec2-001
name: iam:PassRole + ec2:RunInstances
category: new-passrole
services:
- iam
- ec2
description: A principal with `iam:PassRole` and `ec2:RunInstances` permissions can launch a new EC2 instance and attach an existing IAM Role to it. By accessing this new instance (e.g., via User Data or SSM), the attacker can obtain the credentials of the passed role. The level of access gained depends on the permissions of the available roles.
permissions:
required:
- permission: iam:PassRole
resourceConstraints: Target role ARN must be in the Resource section
- permission: ec2:RunInstances
resourceConstraints: Must have permission to launch EC2 instances
additional:
- permission: iam:ListRoles
resourceConstraints: Helpful for discovering available roles to pass
- permission: iam:GetRole
resourceConstraints: Useful for viewing role trust policies and attached permissions
prerequisites:
admin:
- A role must exist that trusts ec2.amazonaws.com to assume it
- The role must have an instance profile associated with it
- The role must have administrative permissions (e.g., AdministratorAccess)
lateral:
- A role must exist that trusts ec2.amazonaws.com to assume it
- The role must have an instance profile associated with it
discoveryAttribution:
firstDocumented:
author: Spencer Gietzen
organization: Rhino Security Labs
date: 2018
link: https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/
references: [ommitted for brevity]
exploitationSteps: [ommitted for brevity]
recommendation: [ommitted for brevity]
attackVisualization: [ommitted for brevity]
detectionTools: [ommitted for brevity]
learningEnvironments: [ommitted for brevity]
这种结构不仅仅是为了网站展示；它是为了让安全工具能够消费而设计的。想检查你的 CSPM（云安全态势管理）是否覆盖了所有基于 Lambda 的 PassRole 提升路径吗？查询 category: service-passrole 和 services: [lambda]：
curl -sk https://pathfinding.cloud/paths.json | jq '.[] | select(.category == "service-passrole" and (.services | contains(["lambda"]))) | {id, name}'
{
"id": "lambda-001",
"name": "iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction"
}
{
"id": "lambda-002",
"name": "iam:PassRole + lambda:CreateFunction + lambda:CreateEventSourceMapping"
}
{
"id": "lambda-006",
"name": "iam:PassRole + lambda:CreateFunction + lambda:AddPermission"
}
想了解 PMapper 遗漏了哪些路径吗？筛选出 detectionTools.pmapper 不存在的路径即可。
curl https://pathfinding.cloud/paths.json | jq '.[] | select(.detectionTools.pmapper == null) | {id, name}'
{
"id": "apprunner-001",
"name": "iam:PassRole + apprunner:CreateService"
}
{
"id": "apprunner-002",
"name": "apprunner:UpdateService"
}
{
"id": "bedrock-001",
"name": "iam:PassRole + bedrock-agentcore:CreateCodeInterpreter + bedrock-agentcore:StartCodeInterpreterSession + bedrock-agentcore:InvokeCodeInterpreter"
}
[and many more...]
七、致谢
感谢 Daniel Grzelak[14] 与我们进行的关于分类法的头脑风暴。在此研究过程中，Daniel 和我意识到我们都在从事类似的项目，并最终形成了双向反馈。Daniel 也即将在这个领域发布一些东西，敬请期待。
八、结论
已记录的权限提升路径与工具覆盖率之间的差距不会自动消失。AWS 持续增加新服务，而每个新服务都会带来新的权限提升变体。但这个差距无需一直隐藏。
pathfinding.cloud 让这些差距变得可见且可操作。安全团队可以准确了解他们的工具遗漏了哪些路径，渗透测试人员可以找到记录不全的技术，而工具开发者则可以确定需要增加覆盖的地方。
如果你负责保护 AWS 环境，我建议你浏览已记录的路径并检查你的工具覆盖范围。如果你是一名研究人员，发现了新的路径或变体，或者发现了归属、或任何其他字段有错误，请提交一个 PR。
我们的目标不仅仅是全面的文档记录。更是为了确保当某人部署了 AWS 安全工具并修复了所有发现的问题后，他们确实关闭了他们自认为已关闭的权限提升路径。
请访问 pathfinding.cloud[2] 探索所有已记录的路径，或查看 github.com/DataDog/pathfinding.cloud[15] 以做出贡献。
引用链接
[1] 《Introducing Pathfinding.cloud》: https://securitylabs.datadoghq.com/articles/introducing-pathfinding.cloud/
[2] pathfinding.cloud: https://pathfinding.cloud/
[3] 攻击者: https://www.invictus-ir.com/news/the-curious-case-of-dangerdev-protonmail-me
[4] 利用: https://securitylabs.datadoghq.com/articles/tales-from-the-cloud-trenches-unwanted-visitor/
[5] Spencer Gietzen: https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/
[6] 撰写了一篇文章: https://bishopfox.com/blog/privilege-escalation-in-aws
[7] IAM Vulnerable: https://github.com/BishopFox/iam-vulnerable
[8] pmapper: https://github.com/nccgroup/PMapper
[9] 后续研究: https://bishopfox.com/blog/assessing-the-aws-assessment-tools
[10] apprunner-001: https://pathfinding.cloud/paths/apprunner-001
[11] 模式: https://github.com/DataDog/pathfinding.cloud/blob/main/SCHEMA.md
[12] paths.json: https://pathfinding.cloud/paths.json
[13] ec2-001: iam:PassRole + ec2:RunInstances: https://github.com/DataDog/pathfinding.cloud/blob/main/data/paths/ec2/ec2-001.yaml
[14] Daniel Grzelak: https://www.linkedin.com/in/danielgrzelak/
[15] github.com/DataDog/pathfinding.cloud: https://github.com/DataDog/pathfinding.cloud
交流群
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito《AWS云权限提升路径大全》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论