Qubole供应链攻击：IAM凭证致十余家企业AWS数据泄露

资讯专家

据 SecurityWeek 报道，研究人员发现一起与大数据平台 Qubole 相关的供应链攻击事件：攻击者利用 Qubole 一个 AWS 账户中被泄露的 IAM 凭证，从十余家组织的 AWS 环境中窃取数据。

攻击路径

对于在客户 AWS 环境中运行的 SaaS 平台来说，跨账户 IAM 角色是常见做法。客户在接入时，会为 Qubole 创建一个角色，供应商的 AWS 账户在需要时可以通过 External ID 承担该角色。此次泄露的 Qubole 凭证使攻击者能够承担这一角色，进而访问并拉取十余家公司的 AWS 环境中的数据。

Sentra 指出，攻击者使用的是“旧门”：许多公司在停止使用 Qubole 之后，为 Qubole 创建的角色仍在 AWS 中保留了很久，而这些角色几乎可以读取攻击者想要获取的所有数据。这些角色一直处于闲置状态，直到本次攻击活动于 10 月 14 日启动，并在 10 月 26 日之前被持续用于枚举资源、收集密钥与配置信息，以及访问数据。

攻击来源与操作特征

Sentra 表示，攻击流量来自一台租用的 OVH 服务器和 Mullvad VPN；在观察到的活动中，没有发现来自 Qubole 自身网络的流量。

与 Sentra 共同分析该活动的 Wiz 指出，攻击者使用的角色会话名称遵循固定格式：前缀为

2. quiam-

复制代码

，后缀用于描述所执行的操作，例如

2. quiam-enum

复制代码

、

2. quiam-scope-full

复制代码

。

在完成资源枚举后，攻击者从常见的 AWS 存储位置收集密钥，随后使用 TruffleHog 验证这些凭证，最后从受害者的 S3 存储桶中外泄数据。Wiz 表示，攻击者看起来是机会主义的：他们并不针对特定数据，而是读取每个角色能够访问的任意存储桶中的数据；在某些情况下，他们在单次会话中下载了整个存储桶。

尚未部署的 ISO 与另一波活动

Wiz 还发现了一个 ISO 文件，该文件被设计为在受害者机器上远程引导，以收集数据，但目前没有证据表明它已被实际部署。

Wiz 表示，目前尚未发现该活动与其他已公开披露的攻击活动存在关联。从目标选择和数据窃取方式看，该活动具有机会主义特征，与典型的国家背景攻击优先级并不吻合；不过，Wiz 也强调，他们并不掌握威胁行为者动机或其后续利用被盗数据方式的直接信息。

此外，Wiz 还发现另一起涉及 Qubole 集成的独立活动，该活动在 10 月 8 日至 10 月 11 日期间活跃。在这起活动中，客户自有的 AWS 访问密钥被用于对受害者环境进行测试，部分场景下还导致了入侵。

处置提示

从披露内容看，攻击的核心问题在于第三方 SaaS 平台遗留的跨账户 IAM 角色：相关角色在业务停用后仍未回收，且权限范围过大。建议使用过 Qubole 或类似 SaaS 集成的组织排查 AWS 中仍存在的第三方跨账户角色，确认 External ID 与信任策略，回收不再使用的角色，并核查相关角色的 CloudTrail 使用记录，其中包括以

2. quiam-

复制代码

开头的会话名。

同时，应轮换可能暴露在 Qubole 集成中的访问密钥，并审计 S3 存储桶的访问日志，评估数据外泄范围。

热心网友3

谢谢分享，这个案例很值得警惕。核心问题确实是第三方 SaaS 遗留的跨账户 IAM 角色：业务停用后角色没回收，权限又过大，结果被泄露的 Qubole 凭证直接承担角色拉数据。建议用 AWS 的组织尽快排查仍存在的第三方跨账户角色，重点看信任策略和 External ID，回收不再使用的角色，并查 CloudTrail 里以 quiam- 开头的会话名及相关角色使用记录。同时轮换可能暴露在 Qubole 集成里的访问密钥，审计 S3 访问日志评估外泄范围。另外那个 ISO 目前虽未发现实际部署，但说明攻击面不止一条，后续排查时也可以顺带确认相关集成和密钥的使用情况。整体看攻击偏机会主义，但“停用不回收角色”这个问题在不少环境里都容易踩坑。

热心网友3

感谢分享，这个案例很值得转给做云安全的同事看。最扎心的点其实不是 Qubole 本身，而是“业务都停了，跨账户角色还留着”——这种遗留信任关系平时没人看，一旦供应商侧凭证泄露，就等于把门钥匙留在了门口。External ID 只能防 confused deputy，防不了供应商账户被攻破，所以权限最小化和角色生命周期管理才是根本。 从处置角度，我觉得除了回收闲置角色、轮换密钥、审计 S3 访问日志，CloudTrail 里以 quiam- 开头的会话名确实是个很好的排查线索，可以顺着 AssumeRole 记录把受影响的时间窗和调用来源串起来。另外也提醒一句，排查时别只盯着还在用的集成，停用项目、临时测试、离职交接留下的角色最容易漏。机会主义攻击不代表危害小，单次会话整桶下载这种手法，对数据敏感的业务来说后果一样很重。那个还没部署的 ISO 也说明攻击者还在尝试扩展手法，不能只看当前有没有中招。

热心网友6

感谢分享，这个案例确实很典型：问题不在 Qubole 本身被直接攻破，而在于第三方 SaaS 集成留下的跨账户 IAM 角色长期没回收、权限又过大，结果成了“旧门”。文中提到的排查方向很实用，尤其是用 CloudTrail 搜 quiam- 开头的会话名、检查信任策略和 External ID、轮换可能暴露的访问密钥，以及审计 S3 访问日志。用过 Qubole 或类似 SaaS 集成的组织最好尽快确认是否还有闲置的第三方角色，别等真出数据外泄再处理。另外攻击者偏机会主义、单次会话下载整个存储桶这一点也提醒大家，存储桶权限和日志审计不能只停留在接入时检查。