IAM AttachUserPolicy 权限提升滥用
原创
钟智强
钟智强
哪吒网络安全
2026年7月4日 18:47
马来西亚
在小说阅读器读本章
去阅读
AWS 云安全技术研究报告
IAM AttachUserPolicy 权限提升滥用
从低权限凭证到账户完全失陷的攻防全过程
| 作者 | 哪吒网络安全 · 钟智强 |
| 文档类别 | 渗透测试技术研究 / 云安全攻防 |
| 目标平台 | Amazon Web Services (AWS) IAM |
| 关键技术 | iam:AttachUserPolicy 权限提升 |
| 适用读者 | 云安全工程师 · 红队 · 蓝队 · 审计人员 |
| ⚠ 合规与免责声明 本报告仅用于授权范围内的安全测试、防御能力建设与安全教育。所有操作均在作者自有的隔离实验账户中完成。 未经书面授权，严禁针对任何不属于自己或未获明确许可的 AWS 环境实施文中技术。因滥用本文内容造成的一切后果由行为人自行承担。 |
一、概述
云计算在带来弹性与效率的同时，也引入了一类区别于传统漏洞的安全风险——身份与访问管理（IAM）的错误配置。与缓冲区溢出、注入等“代码层漏洞”不同，IAM 类风险往往源于权限边界设计不当：当一个本应受限的主体被授予了能够“改写自身权限”的能力时，攻击者无需任何 0day，仅凭一次合法的 API 调用即可完成提权。
本报告聚焦其中极具代表性的一例: iam:AttachUserPolicy 权限滥用。该 API 用于把指定的托管策略附加到指定的 IAM 用户上。若主体被允许对任意资源调用该操作（Resource: \"\*\"），它便可以给自己或他人附加诸如 AdministratorAccess 这样的高权限托管策略，从而突破原有权限边界，一步到达账户管理员。
| ℹ 本文你将获得 • 一套可复现的脆弱 IAM 实验环境搭建步骤； • 基于 AWS CLI 的完整枚举与提权操作流程； • 该技术的检测思路（CloudTrail / GuardDuty）与纵深防御建议； • 其他常见 IAM 权限提升向量的横向对比，帮助举一反三。 |
二、iam:AttachUserPolicy 权限详解
在 AWS 中，权限（Permission） 由 策略（Policy） 这一 JSON 文档承载。策略可被附加到三类主体：用户（User）、用户组（Group）与角色（Role）。iam:AttachUserPolicy 正是把一个“托管策略（Managed Policy）”绑定到“用户”这一主体上的操作。
其危险性在于: 一旦缺少资源级限制（即允许作用于任意用户、可附加任意策略），持有该权限的低权限用户便可主动为自己附加 AWS 托管的 AdministratorAccess（ARN 为 arn:aws:iam::aws:policy/AdministratorAccess），瞬间获得对账户内全部资源的完全控制。
| ⛔ 核心风险点 当某主体的策略同时满足 Action 包含 iam:AttachUserPolicy 且 Resource = \"\*\" 时，即构成可被直接利用的权限提升路径。 |
三、AWS IAM 权限模型基础
在深入利用前，先厘清 IAM 的核心对象关系，有助于理解提权为何成立，以及防御应作用于哪一层。
•IAM 用户（User）：代表一个人或一个应用，持有长期凭证（访问密钥、登录密码）。
•IAM 用户组（Group）：用户的集合，便于批量授权；策略附加到组，组内用户继承。
•IAM 角色（Role）：不绑定固定凭证，通过 STS AssumeRole 获取临时凭证，常用于服务间授权与跨账户访问。
•策略（Policy）：权限的 JSON 载体，分为 AWS 托管、客户托管与内联三类，可附加到上述任一主体。
图 1 AWS IAM 身份与权限模型——策略是权限的载体，可附加到用户/组/角色
四、权限提升原理与攻击链
整条攻击链不依赖任何软件漏洞，全部由“被允许的”合法 API 调用串联而成。攻击者从一份低权限凭证出发，经过身份确认、权限枚举、提权执行三个关键环节，最终获得管理员权限。
图 2 AttachUserPolicy 权限提升攻击链与对应的五个防御拦截点
图中绿色节点标注了每个阶段的防御拦截点：从源头限制长期密钥下发，到 CloudTrail 记录调用、权限边界（Permission Boundary）/ 服务控制策略（SCP）限制提权、GuardDuty 行为告警，直至及时分离高危策略。后文将逐一展开。
五、实验环境与前置条件
为安全复现，请在独立的实验账户中操作，切勿在生产环境演练。
| 项目 | 说明 |
|---|---|
| AWS 账户 | 建议使用专用的隔离测试账户，避免污染生产资源 |
| 攻击主机 | Kali Linux（或任意已安装 AWS CLI v2 的系统） |
| 核心工具 | AWS CLI v2、jq（可选，用于美化 JSON 输出） |
| 实验用户 | Igt\_komal（低权限，附加脆弱策略 vuln\_attached\_policy） |
| 提权目标 | 为自身附加 AdministratorAccess，并验证可执行原本被拒的操作 |
六、第一部分：搭建脆弱实验环境
▍ 6.1 创建过度宽松的托管策略
在 IAM 控制台依次进入 IAM ▸ Policies ▸ Create policy，在 Policy Editor 中粘贴以下 JSON。该策略刻意保留了可被利用的 iam:AttachUserPolicy 通配权限。
| { |
| \"Version\": \"2012-10-17\", |
| \"Statement\": [ |
| { |
| \"Effect\": \"Allow\", |
| \"Action\": [ |
| \"iam:List\\", \"iam:Get\\", |
| \"iam:SimulatePrincipalPolicy\", |
| \"iam:AttachUserPolicy\" ← 高危 |
| ], |
| \"Resource\": \"\*\" ← 无资源限制 |
| }, |
| { |
| \"Effect\": \"Allow\", |
| \"Action\": \"iam:CreatePolicyVersion\", |
| \"Resource\": \"arn:aws:iam::\*:policy/vuln\_attached\_policy\" |
| } |
| ] |
| } |
各 Action 含义如下：
•iam:List\ / iam:Get\：枚举与读取用户、角色、策略等 IAM 资源信息。
•iam:SimulatePrincipalPolicy：模拟评估某主体可执行的操作，常用于审计/测试。
•iam:AttachUserPolicy：向用户附加托管策略——本例的提权关键。
•iam:CreatePolicyVersion：为现有策略创建新版本（本身也是一种独立的提权向量，见第十节）。
填写策略名称 vuln\_attached\_policy 后点击 Create policy 完成创建。
▍ 6.2 创建并授权低权限用户
进入 IAM ▸ Users ▸ Create user，填写用户名 Igt\_komal。在权限设置页选择 Attach policies directly，从列表中勾选上一步创建的 vuln\_attached\_policy，下一步并完成创建。务必妥善保存生成的访问密钥（Access Key ID / Secret）。
| ✎ 为什么用“直接附加”而非组/角色? 直接把策略附加到用户在大规模生产中并不推荐，但在临时排障、隔离环境的精细化测试中较为常见——也正因如此，这类配置成为现实中提权的高发点。 |
七、AWS CLI 速查与凭证配置
后续枚举与利用全程使用 AWS CLI。这里先补充一组常用基础，便于读者理解每条命令。
| 命令 / 概念 | 作用 |
|---|---|
| aws configure | 交互式配置默认凭证与区域 |
| aws configure set ... | 以非交互方式写入指定档案的某项配置 |
| --profile | 指定使用哪个命名档案（多身份切换的关键） |
| aws sts get-caller-identity | 确认“我现在是谁”——返回 UserId / Account / ARN |
| ~/.aws/credentials | 凭证与档案的本地存储位置 |
| ✔ 实用技巧 • 用 --output json 配合 |
八、第二部分：枚举与利用
▍ 8.1 使用场景说明
AttachUserPolicy 将托管策略直接关联到具体用户。虽不适合大规模或生产用途，但在以下受控场景中确有其用，也正是这些“图方便”的用法埋下了隐患：
•测试或排查访问问题；
•在不改动组/角色的前提下快速授予权限；
•小型或隔离环境中的精细化权限控制。
▍ 8.2 配置档案与身份枚举
首先在 AWS CLI 中以受害者用户的密钥建立命名档案 Igt\_komal，随后确认身份并列出当前用户已附加的托管策略。
图 3 配置凭证档案、确认身份并枚举已附加策略
输出清晰显示当前用户仅附加了一条策略 vuln\_attached\_policy，记下其 PolicyArn，下一步据此读取策略文档内容。
▍ 8.3 分析策略文档，定位提权点
列出该策略的所有版本可见 v1 为默认（生效）版本；再读取 v1 的文档内容，便能确认其中包含通配的 iam:List\、iam:Get\ 以及关键的 iam:AttachUserPolicy。
图 4 读取策略版本与文档——确认存在 iam:AttachUserPolicy 通配权限
| ⚠ 判定结论 策略允许对 Resource: \"\*\" 执行 iam:AttachUserPolicy，意味着当前用户可为任意用户（含自己）附加任意托管策略——提权条件成立。 |
▍ 8.4 枚举用户，识别高价值目标
列出账户内全部 IAM 用户，可发现一个命名为 Igt\_admin 的潜在目标；进一步查询确认其拥有 AdministratorAccess。这一步既用于侦察，也为横向移动提供选择（攻击者也可直接给自己提权）。
图 5 枚举账户内用户并确认管理员目标 Igt\_admin
▍ 8.5 执行权限提升
真正的提权发生在下面这一步。先做对照实验：当前用户尝试 create-user 被拒绝。随后调用 attach-user-policy 给自己附加 AdministratorAccess，再次执行同样操作即告成功。
图 6 对照实验 → 自附加 AdministratorAccess → 提权成功
| ⛔ 提权完成 用户 Igt\_komal 已从受限用户跃升为账户管理员，可创建用户、读取/修改任意资源。 |
九、攻击链复盘与分析
整个过程未利用任何传统意义上的“漏洞”，纯粹是权限边界设计不当被合法滥用的结果。提权路径可概括为：
| ✎ 提权路径 低权限 IAM 用户 → 经 iam:AttachUserPolicy 附加 AdministratorAccess → 获得完全管理员权限 → AWS 账户失陷 |
攻击者一旦取得管理员权限，可进一步: 建立隐蔽后门用户与密钥、关闭或篡改 CloudTrail 日志、横向访问 S3/RDS 数据、利用资源进行挖矿或勒索。换言之，单点 IAM 错配足以导致整个账户的连锁失陷。
十、其他常见 IAM 权限提升向量
AttachUserPolicy 只是众多 IAM 提权方式之一。安全研究界（如 Rhino Security Labs）已系统梳理出二十余种路径。下图与表格帮助横向对比，便于在审计时全面排查。
图 7 常见 IAM 权限提升向量风险对比（仅供相对参考）
| 权限 / 向量 | 提权方式 | 等级 |
|---|---|---|
| iam:AttachUserPolicy | 为用户附加 AdministratorAccess | 高危 |
| iam:PutUserPolicy | 为用户写入内联管理员策略 | 高危 |
| iam:CreatePolicyVersion | 将现有策略改写为新的默认版本 | 高危 |
| iam:SetDefaultPolicyVersion | 切换默认版本到更宽松的旧版本 | 高危 |
| iam:AttachRolePolicy | 向可被假冒的角色附加策略 | 较高 |
| iam:CreateAccessKey | 为高权限用户新建访问密钥 | 较高 |
| iam:PassRole + ec2:RunInstances | 把高权限角色传给 EC2 实例 | 较高 |
| iam:PassRole + lambda:CreateFunction | 用高权限角色运行 Lambda | 中 |
| iam:UpdateAssumeRolePolicy | 改写角色信任策略以便假冒 | 中 |
| ℹ 共同特征 这些向量的本质都是“能修改身份/权限配置”或“能把高权限角色传递给可控计算资源”。防御思路因此高度一致：最小权限 + 资源级限制 + PassRole 约束 + 监控告警。 |
十一、风险评级
按“影响程度 × 发生可能性”二维评估：该问题的影响为严重（账户完全失陷），可能性为中（取决于是否存在错误配置）。综合落入高风险区间，应优先治理。
图 8 风险评级矩阵——AttachUserPolicy 权限提升落点
十二、检测与监控
由于全程为合法 API 调用，检测的关键不在“拦截非法请求”，而在“识别异常的权限变更模式”。以 CloudTrail 为数据源，可串联起检测、告警与自动响应。
图 9 以 CloudTrail 为核心的权限提升检测与响应架构
应重点监控的 CloudTrail 事件（eventName）:
| AttachUserPolicy PutUserPolicy CreatePolicyVersion |
| AttachRolePolicy SetDefaultPolicyVersion CreateAccessKey |
| UpdateAssumeRolePolicy CreateUser CreateLoginProfile |
•CloudWatch Logs 指标筛选器：对上述事件设置指标，并对“为自身附加管理员策略”这一模式触发实时高优先级告警。
•Amazon GuardDuty：可识别 PrivilegeEscalation 类异常行为，作为基于行为基线的补充检测。
•EventBridge + Lambda：匹配到高危事件后自动通知（SNS）并执行响应，例如自动分离非预期的高权限策略。
•IAM Access Analyzer：持续发现过宽的权限与外部可访问资源，化被动检测为主动收敛。
十三、防御与加固建议
1.遵循最小权限原则：非必要不授予 iam:AttachUserPolicy、iam:Put\*Policy、iam:CreatePolicyVersion 等可改写权限的高危操作。
2.施加资源级限制：避免 Resource: \"\*\"；用 Condition 限定可附加的策略 ARN，明确禁止附加 AdministratorAccess。
3.善用权限边界与 SCP：通过 Permission Boundary 限制用户能获得的最大权限；在组织层用 SCP 全局禁止危险提权动作。
4.以组/角色替代直接附加：按职能通过用户组或角色集中授权，减少散落在个体用户上的高危直附策略。
5.及时分离高危策略：定期巡检并立即从低权限用户上摘除非预期的高权限策略。
6.强制 MFA 与密钥轮换：对敏感 IAM 操作要求 MFA；定期轮换、回收闲置的长期访问密钥。
7.开启全面审计与告警：CloudTrail 全区域记录 + CloudWatch/GuardDuty 告警，对提权事件实时响应。
8.周期性 IAM 审计：结合 Access Analyzer 与凭证报告，发现未使用或风险策略并持续收敛。
| ✔ 一条可直接落地的 SCP 思路 在组织策略中显式 Deny 对 arn:aws:iam::aws:policy/AdministratorAccess 等高权限策略的 AttachUserPolicy / AttachRolePolicy 操作，可在源头切断“自我提权到管理员”这条最短路径。 |
十四、总结
本实验展示了 AWS 中一类典型且严重的安全风险：错误配置的 IAM 权限。这类提权不依赖传统漏洞，而是源于薄弱的权限边界——一个被过度授权的低权限用户，足以将整个账户拱手相让。
防御的核心始终是最小权限、资源级约束 与持续监控。把权限当作攻击面来管理，定期审计、即时告警、自动响应，才能让“一步到管理员”这类路径无处遁形。
哪吒网络安全 · 钟智强
云安全攻防研究 · 仅供授权测试与防御教育用途
哪吒网络安全 #AWS #IAM
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论