本文以 Decepticon 标准技能库中的aws-iam-enum技能为核心，完整拆解其五步工作流——身份确认、策略采集、Rhino Security Labs 21 条 IAM 提权原语逐一比对、知识图谱晋升与常见攻击链组合，并深入其底层iam_policy_audit工具的源码实现与单元测试，帮助读者掌握"拿到一组 AWS 凭据后，如何在 Decepticon 中系统化地把 IAM 权限映射成可验证的提权路径"这一完整能力。

1. 技能定位：一个可被 Agent 调度的 IAM 枚举剧本

aws-iam-enum是 Decepticon 标准技能树（packages/decepticon/decepticon/skills/standard/cloud/）下cloud子域的技能文件，其完整路径为 aws-iam-enum/SKILL.md。它面向的场景是：渗透者/红队 Agent 已经持有某组 AWS 凭据（环境变量、~/.aws/credentials、EC2 IMDS 角色或泄露的 GitHub Key），需要系统性地回答两个问题——"我现在是谁"以及"我的权限离账号接管有多远"。

1.1 Frontmatter 与技能路由

按照 Decepticon 的 SKILL.md 规范，每个技能文件必须以 YAML frontmatter 开头，CI 会运行python -m decepticon.skill_audit校验。aws-iam-enum的元数据如下：

--- name: aws-iam-enum description: Enumerate AWS IAM policies, detect privilege escalation paths per Rhino Security Labs canonical 21 primitives. metadata: subdomain: cloud when_to_use: "aws iam enumeration privesc rhino security labs 21 primitives policy escalation" mitre_attack: - T1087.004 - T1069.003 - T1078.004 - T1098.003 ---

各字段的作用：

在云子域的技能目录 cloud/SKILL.md 中，aws-iam-enum被列为"Playbooks"表的第一行，与s3-takeover、k8s-pivot、terraform-state-leak、imds-pivot并列；其标准工作流明确写了前三步：

1. `bash("aws sts get-caller-identity")` 2. `bash("aws iam list-attached-user-policies --user-name <me>")` 3. For each attached policy: fetch JSON and `iam_policy_audit`

也就是说，aws-iam-enum是已认证（authenticated）云渗透场景下的入口剧本，其下游产出（策略 JSON、提权原语发现）会被同一工作流第 6 步的kg_add_node + chain edges消化进攻击知识图谱。

2. 第一步：身份确认（Identity check）

技能的第一步是回答"凭据对应哪个主体"，这是后续所有--user-name/--role-name参数推导的基础：

aws sts get-caller-identity aws iam get-account-summary

• aws sts get-caller-identity返回Account、Arn、UserId。Arn同时决定主体类型：role/结尾是实例/服务角色（此时应改用list-attached-role-policies），user/结尾才是 IAM 用户。姊妹技能 aws-iam-passrole-chain/SKILL.md 给出了从 Arn 提取主体名的完整技巧：aws sts get-caller-identity --query Arn --output text | cut -d/ -f2，并给出了角色场景的对应命令（aws iam list-attached-role-policies --role-name $ROLE与aws iam list-role-policies --role-name $ROLE）。
• aws iam get-account-summary返回账号级的 IAM 资源计数（用户/组/角色/策略数量），用于判断该账号是否值得深入枚举。

Decepticon 的 Cloud Hunter Agent 提示词 cloud_hunter.md 对此有对应约束：IAM 发现如果没有可利用性证明只是假设，必须用 AWS CLI 或 boto3 实际验证——"read/list only by default"（默认只做读取/列表操作，不修改线上 IAM）。

3. 第二步：策略全量采集（Attached policies）

身份确认后，技能采集三类策略来源：用户直挂的托管策略、用户内联策略、用户所属组（组的策略会叠加生效）：

aws iam list-attached-user-policies --user-name ME --output json > /tmp/attached.json aws iam list-user-policies --user-name ME --output json > /tmp/inline.json aws iam list-groups-for-user --user-name ME --output json > /tmp/groups.json

对每一条附着的托管策略 ARN，还需要取到其默认版本的完整策略文档：

aws iam get-policy --policy-arn ARN --query 'Policy.DefaultVersionId' aws iam get-policy-version --policy-arn ARN --version-id VID > /tmp/policy.json

拿到/tmp/policy.json后，技能调用 Decepticon 的本地审计工具：

iam_policy_audit(open("/tmp/policy.json").read())

这个调用不是伪代码——iam_policy_audit是 Decepticon 云工具包中的真实 LangChain 工具。下面结合源码拆解它到底做了什么。

3.1iam_policy_audit工具层实现

工具定义在 tools/cloud/tools.py（L24-L32）：

@tool def iam_policy_audit(policy_json: str) -> str: """Audit an AWS IAM policy JSON for privilege escalation primitives. Flags the Rhino Security Labs canonical privesc paths plus wildcard action/resource pairs. """ findings = analyze_iam_policy(policy_json) return _json([f.to_dict() for f in findings])

它把策略 JSON 字符串交给纯 Python 分析器analyze_iam_policy，并将IAMFinding对象序列化为 JSON 列表返回给 LLM——id、severity、title、detail、action、resource六个字段，Agent 可直接据此生成图谱节点。

3.2 内置的提权原语表_PRIVESC_PRIMITIVES

真正的检测逻辑在 tools/cloud/aws.py。模块 docstring 开宗明义：实现遵循 Rhino Security Labs 的经典提权路径，"不复制整个矩阵，只标记高价值原语"。内置映射表覆盖了 12 条核心原语，并各自标注了严重度：

3.3 通配符、NotAction 与 Deny 的边界处理

analyze_iam_policy（aws.py L119-L211）按 Statement 逐条扫描，几个关键设计点值得注意：

1. 只处理Effect: Allow。Deny语句直接跳过，单元测试test_deny_statements_ignored（test_cloud.py L29-L33）验证了这一点：对Deny iam:CreateAccessKey的策略，分析器返回 0 条发现。
2. 双通配是最高优先级。Action=*且Resource=*的 Allow 语句被标记为 critical 级 "Wildcard Action on Wildcard Resource"，detail 直接写明 "account takeover"。
3. 服务族通配。Action形如s3:*且Resource=*时，标记为 high 级 "Wildcard s3:* on all resources"，提示该服务族全账号可用。
4. NotAction不等同于 Action 白名单。这是最容易误报的分支：Effect=Allow+NotAction在语义上是"授予除列出动作之外的所有动作"，因此代码只在Resource=*时输出一条 high 级的 "near-wildcard" 发现（列出被排除的动作），而不会把NotAction里的条目当成正向授权的提权原语去匹配——test_notaction_does_not_match_privesc_primitive（L53-L60）专门保证了NotAction: ["iam:CreateAccessKey"]不会被误报为 CreateAccessKey 提权点。
5. 显式空 Action 不产生幻影通配。按 key 是否存在分支（"Action" in stmt）而非真值判断，Action: []的语句不授予任何权限、不落入["*"]兜底，test_empty_action_produces_no_phantom_wildcard（L62-L64）对此有验证。
6. 解析失败降级为 info 发现。非法 JSON 返回id="iam.parse-error"、severity="info"的单条结果（L124-L127），工具链在 test_cloud_tools.py 的TestIamPolicyAuditWrapper中对解析错误路径与通配符路径都有端到端断言。

3.4 技能清单与代码实现的对照关系

技能文档列出的 21 条原语（下一节完整给出）与_PRIVESC_PRIMITIVES的关系是：文档给全量人工比对清单，代码给自动化高置信度检测。iam_policy_audit自动标记 12 条高危项（如iam:CreateAccessKey、iam:PassRole），而iam:CreateLoginProfile、iam:AddUserToGroup、iam:UpdateAssumeRolePolicy、glue:CreateDevEndpoint、codebuild:CreateProject等其余条目则由 Agent 依据技能清单人工（或由 LLM）比对策略 JSON 完成——aws-iam-enum的设计是"自动检测 + 全量清单兜底"的双层结构。

4. 第三步：21 条提权原语逐一比对

技能文档的第三节是 Rhino Security Labs 的经典 21 条 IAM 提权路径，原则是"对这些动作的任意Allow都是攻击链的一环"。完整清单如下（原样继承自技能文档）：

1. iam:CreateAccessKey（其他用户）
2. iam:CreateLoginProfile
3. iam:UpdateLoginProfile
4. iam:AttachUserPolicy/iam:AttachGroupPolicy/iam:AttachRolePolicy
5. iam:PutUserPolicy/iam:PutGroupPolicy/iam:PutRolePolicy
6. iam:CreatePolicyVersion（当 SetAsDefault=true 时）
7. iam:SetDefaultPolicyVersion
8. iam:PassRole+lambda:CreateFunction+lambda:InvokeFunction
9. iam:PassRole+ec2:RunInstances
10. iam:PassRole+ecs:RunTask/UpdateService
11. glue:CreateDevEndpoint/UpdateDevEndpoint
12. cloudformation:CreateStack配合iam:PassRole
13. datapipeline:CreatePipeline
14. lambda:UpdateFunctionCode（对已带高权执行角色的存量函数）
15. iam:AddUserToGroup
16. iam:UpdateAssumeRolePolicy
17. iam:CreateRole+sts:AssumeRole
18. codebuild:CreateProject配合iam:PassRole
19. sagemaker:CreateTrainingJob配合iam:PassRole
20. aws-marketplace:Subscribe（少见，但已记录）
21. sts:AssumeRole（直接）

其中第 8—11、13、18、19 条都属于PassRole 组合链：单独持有iam:PassRole不构成提权，必须与"能把角色挂到计算实例上的服务 API"配对才成立。这正是姊妹技能 aws-iam-passrole-chain/SKILL.md 展开的利用面——它为 Lambda、Glue Dev Endpoint、EC2 实例配置、SageMaker Notebook 四条路径给出了完整的create-function/create-dev-endpoint/run-instances/create-notebook-instance命令模板，以及 Pacu（iam__privesc_scan）17 种方法的对照表。在 Decepticon 里，aws-iam-enum负责"发现并定性"，aws-iam-passrole-chain负责"利用与验证"，两者构成枚举—利用的上下游关系。

5. 第四步：图谱晋升（Graph promotion）

发现提权原语后，技能要求把结论晋升为攻击知识图谱节点，而不是停留在终端输出：

kg_add_node(kind="vulnerability", label="IAM:CreateAccessKey → account takeover", props={"severity":"critical","source":"aws-iam"}) kg_add_node(kind="crown_jewel", label="AWS Account 1234") kg_add_edge(src=<vuln>, dst=<crown_jewel>, kind="grants", weight=0.3)

语义上：把"持有iam:CreateAccessKey即可接管账号"记为一个vulnerability节点（带严重度与来源属性），把 AWS 账号记为crown_jewel（皇冠宝石，即最终目标）节点，再用grants类型的有向边把"该漏洞直接通向该目标"表达出来。cloud_hunter.md的操作循环第 5 步与此完全一致："CHAIN — promote findings as nodes, link with enables/leaks/grants"，第 6 步再validate_finding做可利用性验证。图谱化的意义在于：后续 Agent 可以通过图谱遍历把 IAM 发现与上游的凭据获取路径（如 SSRF 元数据接管、Terraform state 泄露）自动串成完整杀伤链，供算法规则评估优先级。

6. 第五步：两条典型攻击链

技能最后给出两条高频组合，作为清单比对时的"模式记忆"：

• Dev 用户持有iam:PassRole+lambda:CreateFunction+ 一个带 admin 权限的 Lambda 角色：创建恶意 Lambda 并以该角色运行，直接假定管理员身份。对应利用命令模板见aws-iam-passrole-chain的 Phase 2（aws lambda create-function --role arn:aws:iam::ACCT:role/TARGET_ROLE后invoke取回角色凭据）。
• iam:UpdateLoginProfile+sts:GetFederationToken：重置目标用户的控制台登录配置，获取目标用户的临时控制台访问。

两条链的共同点：都不需要单一"超级权限"，而是两条普通权限的乘积——这也是技能文档反复强调"anyAllowon these is a chain step"的原因。

7. 在 Decepticon 中的完整调用位置

把技能放回 Agent 运行时的位置，完整调用链是：

1. 技能召回：Cloud Hunter Agent（cloud_hunter.md）按when_to_use关键词命中aws-iam-enum，进入 "Lane B — IAM policy audit"：bash("aws iam get-user-policy --user-name X --policy-name Y")取策略 →iam_policy_audit(json)审计 → 每个提权原语生成 vuln 节点并连enables边到下一跳能力（lambda、s3、ec2）。
2. 工具执行：iam_policy_audit等 6 个云工具（连同s3_buckets_from_text、user_data_secrets、k8s_audit、tfstate_audit、metadata_endpoints）统一注册在 tools/cloud/tools.py 的CLOUD_TOOLS列表中，由 tools/cloud/init.py 导出。包 docstring 明确了分工："所有扫描器是纯 Python，对 Agent 粘贴的 JSON/YAML/HCL 字符串离线分析；网络利用（实际签名、凭据使用）留在 bash 通道——本包标记该测什么，而不是替你测"。
3. 结果落图：发现经kg_add_node/kg_add_edge进入攻击图谱，供plan_attack_chains一类的链路规划消费。

8. 使用前提与操作边界

• 凭据前提：全部命令要求本机已配置可用 AWS 凭据（环境变量 / profile / 实例角色），且当前主体对目标用户至少具备相应iam:List*/iam:Get*读权限；get-policy-version还需要iam:GetPolicyVersion。
• 权限边界：该技能是纯枚举+审计剧本，所有写操作（创建 Lambda、重置登录配置等）在 Decepticon 中属于aws-iam-passrole-chain及后续利用技能的职责，且 cloud_hunter.md 的 CRITICAL_RULES 明确要求：未经明确授权，不得执行破坏性动作（删桶、摘策略、修改线上 IAM），默认只允许 read/list。
• 检测器边界：iam_policy_audit是静态策略分析，命中结果表示"策略上存在该原语"，是否真正可达还受Deny语句、资源级条件、服务关联限制影响——源码只处理Allow语句，因此实际可利用性仍需按技能提示用 CLI 实证（这也是 Cloud Hunter 循环中VALIDATE步骤存在的意义）。
• 技能合规：frontmatter 必须满足 docs/skill-schema.md 的必填项（name、description、metadata.subdomain、metadata.when_to_use、MITRE 归因），本地可用make audit-skills校验，CI 对每次 PR 运行校验器。

9. 小结

aws-iam-enum把 AWS IAM 渗透中最基础也最容易做漏的环节——"我是谁、我挂了哪些策略、这些策略里藏着哪几条提权原语"——固化成了五步可执行剧本：身份确认（sts get-caller-identity）→ 三源策略采集（attached/inline/group）→iam_policy_audit自动检测（12 条内置高危原语 + 通配符/NotAction 边界处理，实现与测试分别位于 aws.py 和 test_cloud.py）→ 对照 Rhino Security Labs 21 条清单人工补齐 → 图谱晋升（vulnerability/crown_jewel 节点 +grants边）。配合aws-iam-passrole-chain的利用剧本与 Cloud Hunter 的验证循环，Decepticon 将"策略 JSON"到"攻击图谱中的接管路径"这条链路完全自动化，且每个发现都保留了源码可查、测试可证的实现依据。