2026-07-08 04:43:12 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文详细剖析AWS环境中iam:AttachUserPolicy权限滥用导致的提权风险。当低权限用户的该API被配置为允许对任意资源操作时，攻击者可通过合法调用为自己附加AdministratorAccess托管策略，实现从低权限到账户管理员的直接提权，导致账户完全失陷。文章提供了完整的实验环境搭建与CLI利用流程，并横向对比了其他IAM提权向量。防御建议强调遵循最小权限原则并施加资源级限制，结合权限边界与SCP策略阻断高危操作，同时依赖CloudTrail与GuardDuty构建实时监控与自动响应体系以实现纵深防御。 综合评分： 92 文章分类： 云安全,渗透测试,漏洞分析,安全建设

cover_image

IAM AttachUserPolicy 权限提升滥用

原创

钟智强钟智强

哪吒网络安全

2026年7月4日 18:47 马来西亚

在小说阅读器读本章

去阅读

AWS 云安全技术研究报告

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 行为告警，直至及时分离高危策略。后文将逐一展开。

五、实验环境与前置条件

为安全复现，请在独立的实验账户中操作，切勿在生产环境演练。

六、第一部分：搭建脆弱实验环境

▍ 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。这里先补充一组常用基础，便于读者理解每条命令。

| | | — | | ✔ 实用技巧 • 用 –output json 配合 | jq 可让冗长输出更易读； • 多套凭证可用不同 –profile 隔离，便于在“受害者”与“攻击者”身份间快速切换； • 攻防演练前先 get-caller-identity 自检，避免误操作错误账户。 |

八、第二部分：枚举与利用

▍ 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 权限提升向量风险对比（仅供相对参考）

| | | — | | ℹ 共同特征这些向量的本质都是“能修改身份/权限配置”或“能把高权限角色传递给可控计算资源”。防御思路因此高度一致：最小权限 + 资源级限制 + PassRole 约束 + 监控告警。 |

十一、风险评级

按“影响程度 × 发生可能性”二维评估：该问题的影响为严重（账户完全失陷），可能性为中（取决于是否存在错误配置）。综合落入高风险区间，应优先治理。

图 8　风险评级矩阵——AttachUserPolicy 权限提升落点

十二、检测与监控

由于全程为合法 API 调用，检测的关键不在“拦截非法请求”，而在“识别异常的权限变更模式”。以 CloudTrail 为数据源，可串联起检测、告警与自动响应。

图 9　以 CloudTrail 为核心的权限提升检测与响应架构

应重点监控的 CloudTrail 事件（eventName）:

•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

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：哪吒网络安全钟智强钟智强《IAM AttachUserPolicy 权限提升滥用》