文章总结： 文章揭示了一种跨主流云服务（GoogleCloud、AWS、Azure）的存储桶劫持攻击手法。攻击者利用桶名全局唯一的特性，通过删除目标桶并在自己账户下重建同名桶，即可将日志、消息等数据流劫持至攻击者环境。该攻击不依赖新漏洞，而是利用架构设计缺陷和过宽的权限。防御需收紧删桶权限、使用区域化命名空间并加强监控。 综合评分： 87 文章分类： 漏洞分析,云安全,红队,渗透测试,威胁情报

云存储桶劫持：全球命名空间如何成了数据窃取的完美通道

幻泉之洲

2026年7月5日 10:58 北京

在小说阅读器读本章

去阅读

我们最近挖出一种跨主流云服务的攻击手法——桶劫持。它不靠新漏洞，而是利用存储桶名全局唯一这个设计常识，通过删除后重建同名桶，把别人的数据流悄悄拉到攻击者账下。在 Google Cloud、AWS 和 Azure 的模拟里，日志、消息、文件都能被截胡，攻击者全程隐身。问题根源在于云平台给桶名定的规矩，加上权限撒得太宽。文章不光说怎么攻击，也拆解了为什么防不住，以及该从哪儿下手堵。

要点概述

我们最近发现一种存储桶劫持技巧，横跨多个主流云服务商。这招钻的不是零日漏洞，而是一个所有云平台都绕不开的架构特性：存储桶名得全局唯一。攻击者只要删掉目标桶，再用同名在自己的账户里重建，就能把数据流改道。关键是，整个过程几乎没痕迹，数据流水线照旧运转，运维那边看不出异常。

我们已经在 Google Cloud、AWS 和微软 Azure 上复现了这套手法，并把发现同步给了三家。目前还没在实际攻击里撞见过这招，但说实话，这玩意儿要真被用起来，凭现有监控大概率抓不住。所以趁早堵上，比事后救火强。

▲ 图1：存储桶劫持的攻击流程

攻击的三个支撑点

要说清楚桶劫持怎么搞，得先拆三个设计因素。拧在一起，才给了攻击者机会。

数据流是什么

数据流就是一串自动运转的管道，把遥测、审计日志这些从源头搬到指定存储桶。配置完就自己跑，像 Google Cloud 的日志汇或者 AWS 的桶复制，都是例子。日志汇主要把日志路由到集中存放的桶里，也能导出到 Google Cloud Storage；桶复制干脆把 S3 桶里的东西自动镜像一份到目标桶。这些管道是基建的神经节点，但出问题时也最要命。

全局唯一的桶名

不管 AWS S3 还是 Google Cloud GCS，桶名在云里是绝对唯一的。两个用户不可能起同一个名。这个设定本来是为了省事：数据流一配目标就搞定。可它也有个副作用：桶的身份完全靠名字，不跟账户绑死。名字空出来，谁抢到就听谁的。这就是桶劫持的逻辑原点。

改数据流目的地要什么权限

数据流靠路由资源配置，要改目的地通常得拿特定权限，比如 Google Cloud 日志汇需要 logging.sinks.update。但我们发现，删桶这个操作——跟改路由半点关系没有——反而能直接劫持整个流。删桶的权限，比如 storage.buckets.delete，越了权还能理直气壮。

攻击怎么玩

这套路的步骤简单到让人冒冷汗。攻击者先攻进云环境，拿到删目标桶的权限。接着，把原桶删掉，马上用自己的账户重建同名桶。数据流还傻傻地往那个名字写，东西就全进了攻击者的口袋。图1 画了这个流程。

我们在 Google Cloud 日志里复现了一遍。先建个汇，把日志路由到 GCS 桶。日志正常流。

▲ 图2：一个现有日志汇指向 GCS 桶

然后把桶删了。

▲ 图3：删掉日志汇用的目标桶

再在攻击者的项目里用同一个桶名重建。

▲ 图4：在外部项目重建同名桶

日志就这么被导进别人的桶，攻击者能拿到环境的海量信息。需要的权限只有 storage.objects.delete（清空桶）和 storage.bucket.delete（删桶）。看这权限目录，跟日志路由八竿子打不着。

▲ 图5：日志成功写进攻击者控制的桶

不只日志，一堆服务都中招

数据流往 GCS 桶里写，不是日志汇独有。我们测了 Pub/Sub 和 Storage Transfer Service，发现这问题跟传染病一样扩散。

Pub/Sub 是异步消息服务，解耦上下游。发布者往主题发消息，订阅者拉走。架构简单：

1. 发布者发消息到命名通道（主题）。
2. 主题存消息当缓冲。
3. 订阅者通过订阅配置拉消息，可以推模式或拉模式。

我们模拟了桶劫持：

1. 建个 Pub/Sub 主题和链接 GCS 桶的订阅。
2. 给桶配权限——Storage Object Creator 和 Storage Legacy Bucket Reader——好让服务代理访问。
3. 发条消息，成功抵达原桶。
4. 删掉原桶，在另一项目（攻击者的）重建同名桶。
5. 再发消息，消息直接被劫到攻击者环境。

消息流说拐就拐，这证明桶劫持对 Pub/Sub 完全管用。

Storage Transfer Service 是个托管数据迁移工具，批量搬文件，跨云或本地。架构上就是编排引擎，从源到目的。我们配了个传输任务，源桶和目的桶都放 GCS。给桶权限：源桶需 Storage Object Viewer 和 Storage Legacy Bucket Reader；目的桶需 Storage Object Admin。任务启动后，删掉目的桶，在攻击者项目重建。往源桶写个新对象，等任务到调度时间，它出现在攻击者控制的桶里。

这一下把问题面拉大了。删桶权限 storage.buckets.delete 和 storage.objects.delete，能绕过日志汇的 logging.sinks.update、Pub/Sub 的 pubsub.subscriptions.update、传输任务的 storagetransfer.jobs.update 这些精细权限。一个删桶动作，掀翻整条数据链。

换到 AWS，问题一样

桶名全局唯一不是 Google Cloud 的专利。AWS S3 一个路数。我们用 S3 桶复制测了：

1. 在同账户内建两个桶，设复制规则，源到目的。
2. 删掉目的桶，立即在外部账户用同名重建。
3. 往源桶上传文件。
4. 文件自动出现在外部账户的桶里。

不只复制，Amazon Data Firehose 也用 S3 当目的，表现一样。AWS 这块坑，深得跟 Google Cloud 如出一辙。

▲ 图6：重创建桶后，汇配置保持原样且有效

Azure 的缩水版

Azure 上我们试了跨订阅的变种。平台限制，删掉存储账户后，同一个名在不同租户里几天内不能立刻重用，所以不能跨租户玩。但跨订阅行得通。比方说，攻击者在订阅 A 里拿到删存储账户的权限，想到订阅 B（那儿权限更高或之前没数据访问权）里重建。前提是关掉软删，让名字马上释放。

用 Azure Monitor 的诊段设置演示：资源日志能导出到 Azure 存储账户。配置时，目标用 ARM 资源 ID 存，但内部管道解析时靠 DNS 名（{accountname}.blob.core.windows.net）。删掉原存储账户，在同一租户的不同订阅里重建同名，诊段管道照常往里写日志。

严重程度比 AWS 和 Google Cloud 低，毕竟跨不了租户。但照样说明，名号继承这招，平台设计里藏隐患。

权限太宽，给攻击开了后门

桶劫持能落地，十有八九因为角色权限撒得太开。我们挖出两种典型场景：

1. 权限提升：一个身份只要能删桶，就能把数据流改道。现实中，存储管理员角色覆盖 storage.buckets.delete 权限，广泛分配。它不包含改数据流的精细权限，但删桶就足够劫持，相当于用侧门绕开日志汇的 logging.sinks.update 门禁。
2. 路由资源悬空：桶被删，但关联的路由没清。攻击者摸到空名字，建同名桶，数据流自动接入客。

检测这些可太难了。如果目标桶只用于长期存档或备份，没人天天盯着，删了可能毫不知情。数据流自己跑，汇配置看上去正常（图6），运维巡检扫一眼就过。实际上数据正源源不断流进别人口袋。

▲ 图7：预定义的 Google Cloud 存储管理员角色包含桶删除权限（红框），但缺数据流资源的更新权限

过宽的角色是云安全的慢性病。Google Cloud 里，存储管理员角色随手给 storage.buckets.delete，可它不碰日志汇、订阅那些精细权限。这设计好像默认删桶是个无关痛痒的动作，可偏偏动摇了数据流根基。AWS 和 Azure 类似，内置管理权限都慷慨得吓人。

怎么堵？两层防线

堵桶劫持得前后一起抓：预防的硬规矩加上监控的警报线。

预防第一条——权限瘦身。核心删权限得死死管住： • Google Cloud: storage.buckets.delete • AWS: DeleteBucket • Azure: Microsoft.Storage/storageAccounts/delete 这些只给最小角色集合，服务账户或应用别想碰，除非有铁打理由。

再就是边界控制： • 用数据边界策略限制资源只在内网流通。AWS 数据边界政策（通过 SCP 和 VPC 终端点落实）能拦下往外部 S3 桶写的操作，即使攻击者偷换了桶也写不出去。类似地，Google Cloud 的 VPC Service Controls 围起项目和服务，API 调用出不了界。但这招有局限性，比如覆盖不全的混搭环境。 • AWS 的 S3 账户区域命名空间直接消灭桶劫持源头——把桶名锁在账户和区域里，删了桶别人抢不走名字，数据流没机会拐弯。这是最干脆的解法，可惜不是默认选项。

监控也不能松。盯紧存储桶删除操作，优先给高敏数据桶设高严重度告警。环境里删桶可能天天有，所以得靠数据安全态势管理（DSPM）筛出要害资产。像 Cortex XSIAM（图8）对高敏桶的删除告警，就是例子。

▲ 图8：Cortex XSIAM 告警：检测到高敏桶被删除

反思：架构定了安全边界

桶劫持这招，根在云平台自己定的规矩：存储资源名全局唯一，数据流配完就忘。它不是哪个工程师的疏忽，是架构设计留下的缝。我们的模拟跨了三家厂商，说明这不是局部 bug，而是一类通杀的手法。

这事扒开两个点： • 安全边界早被架构框死了。云厂商怎么设计桶名、怎么管理身份权限，直接划定你能防多宽。防护策略光补丁不够，得吃透这些底层逻辑，用护栏把坑填掉。 • 攻击思维别绑死在一家平台上。云之间长得像，发现一个缺陷，就等于拿到另一家的图纸。安全场子要跳出“单云视角”，用跨平台的方法论找薄弱点。

说实话，桶劫持暴露了云上预设信任的脆弱。自动数据流靠名字找目标，就像在快速路上闭眼开车。真要落到实处，把区域化命名做成默认、把删权限收进审计盲区，比花里胡哨的检测来得实在。

Palo Alto Networks 的 Cortex Cloud 通过云运行时安全操作收集、分析、检测云平台和 SaaS 应用的审计日志，有现成规则揪出数据往外部桶移的动作。它的身份安全模块——云基础设施权限管理、身份安全态势管理、数据访问治理和身份威胁检测响应——能改善权限配置错、敏感数据访问异常这些风险。Unit 42 云安全评估[1]也能把云复杂性转成可落地的安全判断。觉得遭受攻击或有紧急事件，联系 Unit 42 事件响应团队：https://start.paloaltonetworks.com/contact-unit42.html。

补充资源

• Google Cloud 聚合汇概览：https://docs.cloud.google.com/logging/docs/export/aggregated_sinks_overview
• AWS 桶复制：https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html
• Google Cloud Pub/Sub：https://docs.cloud.google.com/pubsub/docs/overview
• Google Cloud Storage Transfer Service：https://docs.cloud.google.com/storage-transfer/docs/overview
• AWS Amazon Data Firehose：https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html
• Azure Monitor：https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
• 微软预防子域接管：https://learn.microsoft.com/en-us/ azure/architecture/playbooks/dns-dangling
• Azure 查找悬空 DNS 记录：https://github.com/Azure-Network-Security/CrossProduct/DNS-FindDanglingDNSRecords
• AWS 构建数据边界：https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html
• Google Cloud VPC Service Controls 概览：https://docs.cloud.google.com/vpc-service-controls/docs/overview
• AWS S3 账户区域命名空间：https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-faq.html

参考资料

[1] https://www.paloaltonetworks.com/unit42/assess/cloud-security-assessment

[2] https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/

免责声明：

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

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

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

本文转载自：幻泉之洲 《云存储桶劫持：全球命名空间如何成了数据窃取的完美通道》