Salesforce/Salesloft Drift 数据泄露事件的教训——详细案例研究

2025 年 8 月发生的 Salesloft Drift 数据泄露事件是SaaS历史上最严重的供应链攻击之一，表明单一受损集成可能会引发大范围的组织暴露。

此次复杂的攻击活动由威胁行为者UNC6395发起，利用 OAuth 令牌漏洞访问了 700 多个组织的敏感数据，其中包括 Cloudflare、Palo Alto Networks 和 Zscaler 等主要网络安全供应商。

该事件暴露了第三方应用程序安全性的严重弱点，并为加强企业网络弹性提供了宝贵的经验教训。

最初的入侵：GitHub 帐户泄露

攻击时间表揭示了该攻击在公开披露前几个月就已开始的系统性攻击方式。根据 Mandiant 的调查，威胁行为者 UNC6395 于 2025 年 3 月首次获得Salesloft GitHub 帐户的访问权限，并一直保持访问权限直至 2025 年 6 月。

这次最初的入侵代表着一次严重的安全漏洞，并且三个月来都未被发现。

在此延长的访问期内，攻击者通过在Salesloft 和 Drift应用程序环境中开展侦察活动展示了复杂的操作安全性。

他们系统地从多个存储库下载内容，添加访客用户，并建立工作流程，以便后来进行大规模数据泄露活动。

这段延长的时间使威胁行为者能够彻底了解目标环境并识别最有价值的攻击媒介。

GitHub 的泄露事件凸显了现代软件开发中的一个基本挑战：代码库和开发基础设施的安全性。

Salesloft 尚未透露如何获得最初的 GitHub 访问权限，但这种透明度方面的差距引起了安全分析师的批评，他们强调了解根本原因对于有效补救的重要性。

Drift 平台利用和 OAuth 令牌窃取

在侦察阶段之后，攻击者转而利用 Drift 的 Amazon Web Services (AWS) 环境，并成功获取Drift 客户技术集成的OAuth 令牌。

这代表着严重的供应链漏洞，导致数百个组织遭受大规模攻击。

OAuth 令牌作为数字密钥，授权应用程序跨不同平台访问用户数据，而无需密码验证。

在 Drift 的案例中，这些令牌使聊天机器人平台能够与 Salesforce、Google Workspace 和其他业务应用程序等客户系统集成。

通过窃取这些令牌，UNC6395 有效地继承了相同的可信访问权限，从而可以绕过传统的安全控制。

此阶段的技术复杂性体现在攻击者能够访问 AWS 托管的 OAuth 凭证并在不被发现的情况下提取它们。

这表明他们对云基础设施和令牌管理系统有着深入的了解，这是高级持续性威胁 (APT) 组织的特征。

2025年8月8日至18日期间，UNC6395针对通过Drift集成连接的Salesforce实例发起了系统性数据泄露活动。攻击者采用了复杂的技术，在试图逃避检测的同时，最大限度地窃取数据。

该活动的主要目标是窃取凭证，而非立即将数据货币化。UNC6395 系统地搜索了窃取的数据，以寻找有价值的机密信息，其中包括：

• Amazon Web Services (AWS) 访问密钥（AKIA 格式）
• 与 Snowflake 相关的访问令牌
• VPN 凭证和配置信息
• 通用密码和身份验证字符串
• API 密钥和服务帐户凭据

这种对凭证收集的关注表明了一种旨在实现受害者环境中的二次攻击和横向移动的战略方法。

被盗凭证可以让攻击者持续访问云基础设施和关键业务系统，远远超出最初的 Salesforce 漏洞。

受影响的公司

此次漏洞影响了数量惊人的组织，谷歌威胁情报小组证实数百家公司受到影响。

公开披露的受害者中包括几家著名的网络安全供应商，凸显了供应链攻击的无差别性：

• Cloudflare：已确认在 2025 年 8 月 12 日至 17 日期间对 Salesforce 案例对象进行了未经授权的访问，并发现并轮换了 104 个 API 令牌
• Palo Alto Networks：披露 CRM 平台遭入侵，其中包含业务联系信息和基本案件数据
• Zscaler：承认对 Salesforce 数据（包括客户许可和商业信息）产生影响
• Tenable：客户支持案例信息和业务联系方式被曝光
• Proofpoint：已在多个安全公告中确认受到影响
• Dynatrace：报告称业务联系信息泄露有限，且对核心产品没有影响
• Qualys：确认有限的 Salesforce 访问权限不会对生产环境产生影响
• Cyber​​Ark：披露 CRM 数据泄露事件，同时强调不会泄露客户凭证
• Wealthsimple：报告了更广泛的影响，包括客户的政府身份证和个人信息。

根本原因分析：系统性安全故障

Salesloft Drift 漏洞揭示了多个相互关联的安全故障，这些故障共同造成了灾难性的供应链漏洞：

GitHub 最初的入侵事件表明，代码库和开发基础设施的安全控制不足。主要缺陷包括：

• 关键开发账户的访问控制和监控不足
• 缺乏对未经授权的存储库访问的检测能力
• 延长停留时间（3个月以上）且未检测到恶意活动

攻击者能够从 AWS 环境访问和窃取 OAuth 令牌，这表明凭证管理存在重大缺陷：

• 高价值身份验证令牌保护不足
• 开发和生产环境之间的划分不足
• 缺乏对 OAuth 令牌使用模式的异常检测

组织对第三方集成的监督不足：

• 过度宽松的 OAuth 范围授予集成应用程序过多的访问权限
• 对第三方应用程序行为的监控不足
• 缺乏对连接应用程序的定期安全评估

检测和响应差距

恶意活动持续时间较长（10 天以上），暴露出检测和响应方面的缺陷：

• API 使用模式的实时监控不足
• 异常批量数据提取活动的识别延迟
• 供应商和客户之间威胁情报共享不足

缓解策略

根据此次事件的教训，各组织应实施全面的缓解策略，以解决当前和长期的安全问题：

立即响应行动

OAuth 令牌安全强化：

• 使用相互 TLS（mTLS）或 DPoP（证明所有权）实现发送方约束访问令牌
• 为公共客户端建立刷新令牌轮换策略
• 部署 OAuth 令牌使用异常的实时监控

第三方集成审核：

• 对所有连接的应用程序及其权限进行全面审核
• 实施 OAuth 范围和 API 访问的最小权限原则
• 对关键集成建立定期安全评估

增强监控和检测：

• 部署针对 API 使用模式和批量数据操作的高级分析
• 对可疑的 SOQL 查询活动实施实时警报
• 为合法应用程序的使用建立基线行为配置文件

战略安全改进

供应链风险管理：
组织必须实施全面的第三方风险管理计划：

• 在集成之前进行严格的供应商安全评估
• 建立对供应商安全态势的持续监控
• 实施合同安全要求和 SLA

零信任架构实施：

• 将零信任原则应用于所有第三方集成
• 实施持续验证和最低权限访问控制
• 部署网络分段以限制横向移动的可能性

开发安全性增强：

• 对代码存储库实施全面的安全控制
• 部署开发环境访问实时监控
• 建立安全的软件开发生命周期 (SDLC) 实践

该事件表明，复杂的威胁行为者如何利用信任关系同时对数百个组织产生广泛影响。

随着供应链攻击的复杂性和规模不断演变，从这次攻击中吸取的教训对于寻求保护自己免受未来威胁的组织至关重要。

关键不仅在于实施单独的安全控制，还在于构建能够适应现代网络威胁动态特性的全面、综合的安全程序。