一组被盗的凭据允许攻击者通过利用长期保持活跃的受信任供应商角色，同时入侵超过十家组织。攻击者利用这些凭据从多家公司悄悄提取生产数据库备份和客户资料文件，由于这些访问在系统日志中看起来是合法的，因此绕过了标准的安全检查。
这张图片说明了此次泄露的核心概念：一组被盗的凭据如何允许攻击者触达多个组织。
被遗忘的信任机制
此次泄露发生的原因是，许多公司即使在停止使用该平台后，仍保留着为 Qubole 维护的活跃云角色。这些“休眠”角色仍被授权读取攻击者目标中的几乎所有敏感数据。
这张图片作为文章中描述的供应链攻击的主要视觉呈现。
由于这些组织是按照 AWS 的建议设置的集成，攻击者能够提供正确的 ExternalId 代码。对于云提供商来说，这些活动看起来像是来自 Qubole 本身，尽管流量实际上源自租用的 OVH 服务器和 Mullvad VPN。
“当受信任的供应商遭到入侵时，仅仅遵循最佳实践是不够的，因为攻击者的访问是真实的，并且在每条日志中看起来都是合法的。”
— Inside the Qubole Supply Chain Attack: How Sentra Found It
战术与数据外泄
攻击者最初在低价值角色上进行缓慢的测试阶段，然后迅速转向批量下载数千个客户资料文件。他们最终转向从不同的 VPN 地址提取生产数据库备份，以避免被检测。
为了扩大其影响范围，攻击者使用了多种技术来收集更多凭据，包括从 Secrets Manager 中批量提取密钥、从 SSM Parameter Store 中读取解密参数，以及抓取 EC2 用户数据中的包含密码的启动脚本。
检测与缓解的局限性
Sentra 通过将泄露文件的内容与他们自己的数据地图进行比较，最终将范围缩小到少数几个 S3 存储桶。他们确定 Qubole 是唯一拥有访问这些特定存储桶权限且表现出异常行为的外部身份。
云安全的一个重大局限是，许多存储系统默认不会记录每一次文件读取。虽然加密日志和文件访问日志提供了一些证据，但被盗数据的实际数量可能高于日志中捕获的数量。
此事件表明，如果这些最佳实践允许持久访问，那么在面对供应链攻击时，仅仅遵循最佳实践是不够的。缓解措施需要采用“零信任”方法，将供应商权限缩减到仅为当前所需，并采用数据检测与响应（DDR）来标记受信任身份表现得像攻击者的情况。