Qubole漏洞让厂商的AWS信任变成万能钥匙

2026年10月14日至10月26日期间，有人手持Qubole自身的密钥闯入了数十个客户的AWS账户。这并非盗取了客户账户的密码，而是厂商的凭证，也就是其云数据平台合法用于承担客户为其创建的IAM角色的那套凭证。进入之后，攻击者枚举资源、清空机密存储、用TruffleHog测试窃取到的凭证，部分案例中还下载了整个S3存储桶。相关研究来自The Hacker News和CSO Online。

该活动由AI数据安全公司Sentra发现，Google旗下的Wiz进行了调查，其CIRT分析师Zack Morrow、Sean Johnstone和Benjamin Read发布了技术分析报告，Mandiant事件响应团队也参与其中，据The Register报道。目前尚无任何组织对此归因，攻击目标看起来是机会主义式的，而非间谍行动式的。读到这里，每位安全架构师都该感到不安：许多被攻陷的角色属于早已停用Qubole的组织。信任关系比合同活得更久。

核心机制：一个比厂商存活更久的信任策略

简要说明攻击机制，因为整个攻击本质上就是借用身份进行的一次API调用。Qubole是Idera旗下的数据湖平台，它在客户的AWS账户内运行，以管理计算资源并访问存储，无需客户交出长期有效的访问密钥。标准模式是：客户创建一个IAM角色，该角色的信任策略允许Qubole的AWS账户（805246085872）对其调用sts:AssumeRole。外部ID（External ID）本应作为一种共享知识的校验机制，用来防范混淆代理人攻击。

这使其成为厂商失陷事件，而非客户配置失误，关键在于：外部ID并不被视为机密。根据AWS自身的外部ID指南，任何能查看该角色的人都能看到它。攻击者掌握了Qubole AWS账户的凭证，具体如何获得尚未披露，而Wiz观察到的每一次恶意AssumeRole请求都携带了正确的外部ID并且成功了。这把锁完全按设计运作，只是攻击者手里有钥匙。

这就像潜行类游戏里的经典梯子机制：守卫的制服能让你通过每一道检查点，直到有人吊销这套制服。这里没人吊销它。Wiz发现，许多目标角色在10月份没有任何合法的Qubole活动，平台关系实际上已经终止，但信任策略依然有效，而AssumeRole检查的正是这一点。

10月8日至11日：无人能完全关联的前奏

在调查过程中，Wiz发现了一场单独的活动，于10月8日至11日进行，滥用了另一种集成方式：Qubole还允许客户使用自己的AWS访问密钥而非角色进行连接。攻击者利用了据信为Qubole设置的客户自有密钥，入侵了The Register所描述的少数受害环境。Wiz表示无法明确将其与主要事件关联。这一点仍待确认，但它表明，幕后之人在AssumeRole活动展开之前，至少已经探查Qubole集成接口长达一周。

10月14日至15日：通过Mullvad首次现身

首次确认的恶意活动发生在10月14日。一个与Mullvad VPN关联的IP地址，尝试从Qubole账户中以IAM用户AIDA3W7DIFLYOLTK63SFS的身份承担客户集成角色。Wiz的CIRT团队就这一主体做出了一个尖锐的观察，The Register的报道中有所引用：

在所有受影响的环境中，Wiz CIRT从未观察到该IAM用户有任何与该威胁行为者无关的活动。

这使AIDA3W7DIFLYOLTK63SFS成为标准级的IOC：它出现在你的CloudTrail中，按定义即为恶意。活动在10月15日继续，10月18日，攻击者开始使用同一Qubole账户中的第二个IAM用户AIDAJYRRH5Y3A7AAJM2HW，并配合另一个Mullvad地址。这一项需要谨慎对待：Qubole的合法流量也使用该身份，因此只有当源地址位于AWS之外时才构成IOC。Wiz表示，Qubole的真实流量仅来自AWS基础设施，这为防御者提供了一个清晰的判别依据。

后期的大部分活动来自一台OVH托管的VPS，地址为57.129.54[.]120（及其IPv6对应地址2001:41d0:70d[:]7800::）。Mullvad地址45.83.220[.]211、185.209.199[.]73、89.37.63[.]175属于共享VPN出口，因此仅凭匹配并不能证明什么。攻击者还运行了以quiam-开头的角色会话，例如quiam-enum，这是一个非常好用的狩猎线索。

账户内部：机密存储速通

承担角色之后，攻击手法纯粹是枚举加收割，老实说读起来就像一份在生产规模上执行的CTF权限提升清单。攻击者梳理了S3存储桶、数据库、EC2实例、安全组和IAM身份，然后直奔AWS客户存放核心机密的地方：Secrets Manager、Systems Manager Parameter Store和Lambda环境变量。Sentra报告称，几分钟内就读取了超过100个密码和密钥，此外在下载的文件中还有数千条额外的凭证记录。

接下来是有趣的一步：攻击者将收割到的凭证交给TruffleHog（没错，就是那款开源机密扫描工具）来验证哪些仍然有效。经确认仍可用的战利品包括受害者自己的AWS访问密钥、Microsoft Entra ID服务主体凭证以及Okta OAuth客户端凭证。Wiz的指南明确建议防御者检查身份提供商的登录日志，查找GetCallerIdentity调用中的TruffleHog用户代理。这正是影响范围的担忧所在：这不仅是一次AWS入侵，更是对这些环境所接触的其他一切的凭证中转站。我们此前已见识过实时令牌泄露会如何扩大事件范围，Chainalysis泄露事件暴露了每位用户的实时令牌，将一次入侵变成了逐个客户的轮换苦力活，同样的计算在这里也适用。

在S3上，攻击者的行为是一网打尽：枚举可访问的存储桶和对象，拉取内容，有时在单次会话中拖走整个存储桶。Wiz认为这种机会主义特征说明，目标选择并不符合国家背景攻击的套路：没有筛选，没有预先布置，只是大规模收集。Sentra指出，在观察到的环境中，攻击者没有执行任何写入操作，这与一次盗窃行动相符，而非为破坏或勒索软件做前期布局。

那个（很可能）从未启用的ISO

有一项发现需要厘清哪些是已确认的，哪些仍是理论上的。在攻击者的OVH基础设施上，Wiz发现了一个名为sso_agent.iso的可引导Linux ISO。它收集系统信息，通过TCP 23458端口与服务器通信，并执行远程下发的shell命令；其配置表明Windows系统可能是预定目标。但Wiz未发现该镜像的任何部署，也无法确认它是否曾用于攻击受害者。因此：能力已观察到，实际利用未观察到。这应归入“他们接下来打算做什么”，而非“实际发生了什么”。

最伤人的日志盲区

这部分应该让人感到刺痛。CloudTrail管理事件会记录每次AssumeRole调用和存储桶列举，因此我们知道攻击者确实进入了S3的“储藏室”。但它们不会记录读取了哪些对象。这需要S3数据事件或服务器访问日志，而多家受害者都缺少这些日志，导致响应人员无法确定究竟有什么被带走。你无法界定一个你无法观察到的入侵范围，而“我们不知道被偷走了什么”是给法务团队的最糟糕回答。如果这次事件只能为你的组织带来一件事，那就是一次数据事件审计。

需要狩猎什么，需要修复什么

Wiz的狩猎指南针对的是每个持有Qubole角色的AWS账户中、自10月1日起的CloudTrail记录。核心查询逻辑如下：

eventName = "AssumeRole"
AND userIdentity.accountId = "805246085872"
AND sourceIPAddress NOT AWS-owned   -- Qubole's legit traffic is AWS-internal
-- High-fidelity indicators:
-- userIdentity.principalId = "AIDA3W7DIFLYOLTK63SFS"   (always malicious)
-- principalId = "AIDAJYRRH5Y3A7AAJM2HW" from non-AWS IP (malicious only off-AWS)
-- roleSessionName starts with "quiam-"
-- sourceIPAddress in 57.129.54.120, 2001:41d0:70d:7800::/64 (OVH)
-- userAgent contains "TruffleHog" on GetCallerIdentity

对每个可疑会话，追踪其之后的所有操作：Secrets Manager、Parameter Store、Lambda、S3。并注意The Register提醒的一个陷阱：轮换凭证并不会终止已经签发的临时会话。如果某个角色被承担过，你需要对所有可触及的机密进行完整轮换，而不仅是集成凭证。其中包括Entra ID机密和Okta客户端凭证，因为攻击者也验证过这些。

在结构层面，Wiz的建议读起来像是对你所有SaaS厂商授权的审计模板，而不仅限于Qubole：

• 清除陈旧信任。如果你已弃用某个厂商，请删除其角色。一个没有合法流量的信任策略，就是一扇无人看守的危险之门。
• 限定主体范围。只信任特定的厂商IAM主体，而非整个外部AWS账户。全账户信任正是让Qubole被攻陷自动变成你被攻陷的原因。
• 固定网络路径。添加与已公开的厂商地址段匹配的aws:SourceIp或VPC端点条件。此攻击者通过Mullvad和OVH发起操作，源IP条件本可以让每一次已观察到的请求都被直接拦下。
• 别再把外部ID当作机密。任何有角色访问权限的人都能查看它们。它们是混淆代理人的校验机制，而不是身份认证。
• 启用S3数据事件。多家受害者无法说明究竟有什么被带走。别再做那几家受害者。

Hacker News查询时，Qubole和Idera均未发布声明，Qubole也未回复The Register的询问。目前也不清楚被盗凭证是否已被禁用，或相关活动是否已停止。因此，厂商信任问题本身依然成立：集成模式并非有缺陷，最小权限角色始终优于长期有效的密钥，但它将风险转移到了厂商的凭证管理水平上。本月，这一风险在数十个环境中成为现实，而许多环境的所有者早已忘记了这扇门的存在。