文章总结： AWSCloudTrail存在绕过漏洞，攻击者可通过非生产端点进行静默权限枚举而不产生日志，暴露了日志盲区。AWS通过禁止外部访问非生产端点修复。建议企业关注日志覆盖完整性，避免依赖单一审计源。 综合评分： 86 文章分类： 漏洞分析,云安全,安全运营,漏洞预警

---

AWS 又现 CloudTrail 绕过漏洞：攻击者可以悄无声息摸清你的 IAM 权限

云梦DC 云梦DC

云梦安全

2026年7月28日 11:36 日本

在小说阅读器读本章

去阅读

最近，AWS HackerOne 平台公开披露了一份来自知名云安全研究员 Nick Frichette 的漏洞报告。漏洞本身并不会直接导致数据泄露，也无法提升权限，但它暴露了云安全体系中一个更容易被忽视的问题——日志盲区（Logging Blind Spot）。

很多企业把 CloudTrail 当作 AWS 环境的”黑匣子”。

谁调用了 API？

什么时候调用的？

有没有权限？

有没有攻击者在爆破权限？

这些问题，大多数安全运营团队都会依赖 CloudTrail 来回答。

但如果攻击者能够完成权限探测，却不会留下任何 CloudTrail 日志，会发生什么？

答案就是——蓝队什么也看不到。

---

一、攻击者拿到 AWS Access Key 后，第一件事通常不是攻击

很多人以为，攻击者一旦获得 AWS Access Key，就会立刻创建管理员、删除资源或者下载数据。

事实上，大多数成熟攻击者都会先做另一件事：

权限侦察（Permission Enumeration）。

例如不断尝试调用各种 AWS API：

aws s3 ls
aws iam list-users
aws ec2 describe-instances
aws cloudwatch list-dashboards

攻击者真正关心的是：

• 我有没有读取 S3 的权限？
• 能不能启动 EC2？
• 是否可以读取 Secrets Manager？
• 是否拥有 IAM 管理权限？
• 能不能调用 Lambda？

每一次 API 请求都会告诉攻击者：

“我到底能干什么。”

与此同时，这些失败请求通常都会被 CloudTrail 记录下来。

例如：

• AccessDenied
• UnauthorizedOperation
• Client.UnauthorizedOperation

对于蓝队来说，这些大量失败的 API 请求反而是一种十分明显的攻击特征。

很多 SIEM、GuardDuty、CloudTrail Lake 检测规则都是基于这些日志建立的。

---

二、CloudTrail 为什么如此重要？

CloudTrail 可以理解成 AWS 的审计日志系统。

几乎所有管理类 API 调用都会留下记录，包括：

• 调用了哪个 API
• 谁调用的
• 来自哪个 IP
• 是否成功
• 是否被拒绝

例如攻击者一分钟连续尝试 300 个 API：

iam:ListUsers
ec2:DescribeInstances
kms:Decrypt
lambda:InvokeFunction

即使全部失败，也都会留下完整日志。

SOC 团队往往会第一时间发现：

为什么这个账号一分钟失败了三百多次？

这也是攻击者最容易暴露自己的阶段。

---

三、本次漏洞真正的问题：CloudTrail 什么都不会记录

研究人员发现，CloudWatch 存在多个非生产环境 Endpoint（Non-Production Endpoint）。

这些接口比较特殊：

• 可以正常使用 IAM 凭证访问；
• 会执行正常的 IAM 权限校验；
• 根据权限不同返回不同结果；
• 但是不会生成任何 CloudTrail 日志。

官方测试结果如下。

管理员账户调用：

{
  "DashboardEntries": []
}

无权限账户调用：

AccessDenied

可以看到，两种身份得到的响应完全不同。

也就是说：

攻击者完全可以判断：

当前账号到底有没有 cloudwatch:ListDashboards 权限。

但是更关键的是：

CloudTrail 中没有任何对应日志。

无论管理员身份还是普通身份，CloudTrail 查询结果都是：

events = 0

也就是说：

攻击者已经完成了一次完整的权限探测。

而防守方却完全不知道。

---

四、这就是所谓的 Silent Permission Enumeration

这个漏洞最大的价值，不在于读取了什么数据。

而在于：

攻击者可以静默地了解自己的权限。

例如：

攻击者可以不断测试：

cloudwatch:ListDashboards
s3:ListBuckets
lambda:InvokeFunction
iam:ListUsers
kms:Decrypt

根据 HTTP 返回结果：

• 200 OK
• AccessDenied

即可逐步绘制出整个 IAM 权限画像。

例如最终得到：

✓ 可以读取 S3
✓ 可以启动 EC2
✓ 可以调用 Lambda

✗ 无法管理 IAM
✗ 无法修改 KMS
✗ 无法删除 CloudTrail

对于攻击者来说，这些信息价值极高。

因为后续所有攻击路径都会建立在这些权限基础之上。

---

五、为什么 CloudTrail 没有日志？

问题并不出在 IAM。

IAM 依然正常工作。

真正的问题在于：

攻击者访问的是 AWS 的非生产 Endpoint。

这些 Endpoint 仍然接入了 IAM 身份认证。

却没有接入 CloudTrail 审计链路。

于是出现了一种十分奇怪的状态：

认证：正常

授权：正常

日志：没有

整个权限判断过程已经发生。

但是审计系统却完全不知道。

对于依赖 CloudTrail 的企业来说，这意味着出现了监控盲区。

---

六、AWS 为什么认为这是安全漏洞？

很多人可能会觉得：

既没有数据泄露，也没有权限提升。

为什么 AWS 会认可这份报告？

实际上，AWS 早就公开说明过：

如果某个非生产 Endpoint 可以被正常 IAM 用户访问，并根据权限返回不同结果，但不会记录 CloudTrail，那么这种 CloudTrail Logging Bypass 属于安全问题。

因此，这份报告很快就通过了官方验证。

研究人员实际上已经连续发现了大量类似问题。

涉及服务包括：

• Bedrock
• Security Hub
• Route53
• EventBridge
• Glue
• ElastiCache
• SSM
• Lake Formation
• Neptune
• CloudWatch

说明这种问题并不是 CloudWatch 独有，而是一类云平台内部接口设计带来的安全风险。

---

七、AWS 最终如何修复？

很多人以为：

既然 CloudTrail 没有日志。

那 AWS 应该补日志。

事实上，他们没有这样做。

AWS 采取的是更加彻底的方案：

直接禁止外部账号访问这些非生产 Endpoint。

修复完成之后，再访问这些 Endpoint：

统一返回：

AccessDenied

攻击者已经无法利用这些接口进行权限探测。

从根本上消除了这一类问题。

---

八、这个漏洞真正值得关注的地方

从 CVSS 来看，这只是一个 4.3 分的中危漏洞。

它不会直接导致：

• 数据泄露
• 权限提升
• 远程代码执行

但它揭示了云安全中一个更加值得思考的问题：

日志系统并不一定覆盖所有安全行为。

很多企业认为：

只要开启了 CloudTrail，就拥有了完整的审计能力。

然而现实并非如此。

如果存在没有接入审计系统的接口，即便 IAM 工作正常，攻击者仍然可能在”无人察觉”的情况下完成侦察。

对于蓝队来说，最危险的攻击往往不是漏洞利用，而是看不见攻击正在发生。

---

#

---

免责声明：

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

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

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

本文转载自：云梦安全 云梦DC 云梦DC《AWS 又现 CloudTrail 绕过漏洞：攻击者可以悄无声息摸清你的 IAM 权限》