Databricks安全团队：凭证攻击的检测关键不在登录本身，而在跨身份行为关联

现代网络攻击越来越多地以一次合法登录开场。Databricks安全团队在近期发布的检测指南中描述了一个典型场景：一名数据工程师的个人访问令牌从持续集成日志中泄露，攻击者几分钟内便用该令牌从新IP列出密钥范围、目录和仓库，随后读取一个保存着服务主体凭证的密钥。一小时后，那个服务主体——而非工程师本人——创建了函数、将自己加入管理员组并导出了若干初始化脚本。每一步单独看都可能是正常平台使用，但合在一起是一次完整的入侵。

这篇由Solomon Boyd、Alexis Merritt、Arun Pamulapati、Sam Pezzino和David Veuve撰写的文章提出了一个六阶段模型来组织凭证驱动攻击的检测：获取访问、映射环境、收割更多凭证、寻找可执行路径、建立持久化、收集数据并清理痕迹。但文章真正有迁移价值的论点不是这六个阶段本身——它们与通用攻击链模型并无本质区别——而是关于事件序列化的判断：攻击者很少按直线通过这六个阶段，他们依赖非线性排序，用一组凭证验证环境后，再取另一组凭证从一个没有侦察记录的新身份或新工作区返回。

这意味着一个具体的检测陷阱：如果你只追踪被窃凭证所对应的身份，你会在攻击者切换到新身份的那一刻失去线索。在上述场景中，工程师的令牌被用来读取密钥，但创建函数、加入管理员组和导出脚本全部由服务主体完成。文章明确指出，仅以工程师身份为范围搜索活动会完全遗漏这些事件。正确的做法是将密钥读取与紧随其后的新身份首次活动、IP变化、用户代理变化关联起来，把分散在不同身份下的事件视为同一次入侵的不同片段。

在具体的检测模式上，文章给出了一些可操作的阈值建议。例如，一个身份在一分钟内调用五个以上不同的发现类API（列出密钥范围、目录、模式、外部存储位置、存储凭证、仓库等）不太可能是人在操作界面。密钥收割的典型序列是listScopes、listSecrets、getSecret在多个范围上快速重复出现。权限提升则关注putAcl、addPrincipalToGroup、setAdmin等事件是否来自不熟悉的身份或执行上下文——尤其是从作业运行时内部做出的权限变更，比管理员在控制台做的同类操作值得更多审视。

文章还区分了检测与响应的边界。一旦确认入侵，响应必须覆盖攻击者创建的所有路径，而不仅仅是原始凭证。在示例场景中，撤销工程师的令牌会留下服务主体的凭证、其管理员组成员身份和它创建的函数。完整的响应包括：在账户级别停用身份、撤销个人访问令牌、导出并停止相关计算、轮换攻击者读取过的每一个密钥、移除攻击者创建的持久化路径、删除函数并撤销授权、恢复上下文准入策略。文章特别提到一个容易忽略的时间窗口：服务主体已有的OAuth令牌在停用后仍可存活一小时。

在预防层面，文章将上下文准入控制列为对抗凭证复用的最强控制，因为它评估请求者身份、来源和用途，而非依赖单一网络边界。对于正在脱离VPN的组织，这提供了一种即使没有企业网络锚点也能限制被盗令牌可用范围的机制。

需要指出的是，文中提出的检测阈值是Databricks安全团队基于其平台运营经验给出的启发式建议，并非经过公开基准验证的测量结果。文章本身也提醒读者将这些指导视为起点，需要根据自身环境的正常自动化模式进行调优。此外，该方法的具体实现深度绑定Databricks的审计日志架构和Genie检测应用，迁移到其他平台需要重新识别对应的事件字段和查询模式。