事件背景：隐蔽的身份审计威胁
近期，安全研究机构披露了一项针对 Microsoft Entra ID（原 Azure AD）环境的新型攻击手法——OAuth Client ID 伪造。攻击者通过构造伪造的 Client ID 发起认证请求，不仅能够进行大规模的账号枚举，还能在不产生“成功登录”记录的前提下，验证窃取凭据的有效性。
从我们的应急响应经验来看，攻击者正不断寻求绕过传统监控规则的方法。该技术目前已被发现应用于两个独立的攻击集群，影响了数千个租户，受影响用户规模超过 300 万。
攻击链分析：如何实现“无痕”枚举
这一环节是很多企业容易忽视的盲区。在正常的 OAuth 2.0 流程中，Client ID 用于标识发起认证请求的应用程序。Entra ID 会将此 ID 记录在登录日志中，以便管理员审计。
攻击者利用了 Entra ID 处理机制的一个特性：当请求中包含一个伪造的、不存在的 Client ID 时，系统仍会处理该请求，但在日志中会将“应用程序名称”显示为空白。攻击者正是利用这一点，通过发送大量针对性的 POST 请求，基于 OAuth 2.0 的 ROPC（资源所有者密码凭据）流进行交互。
技术手法深度解析
攻击者通过分析返回的 AADSTS 错误代码来判断目标的账号状态：
- 账号枚举：通过请求验证用户名是否存在。
- 凭据验证：利用特定的错误代码（如 AADSTS700016），攻击者能够准确判断输入的密码是否正确，而无需真正触碰登录成功后的令牌发放流程。
由于所有请求都使用了伪造的 Client ID，且应用名称字段缺失，企业内部原本设置的“针对特定应用异常流量”的告警规则会直接失效，导致攻击者能够长时间潜伏并进行大规模扫描。
攻击组织与趋势
目前监测到的两个活跃集群（分别被标记为 UNK_pyreq2323 和 UNK_OutFlareAZ）展现了不同的技术成熟度：
- UNK_pyreq2323：主要通过 AWS 基础设施发起，通过随机化已知标识符的末尾数字来生成伪造 ID。
- UNK_OutFlareAZ：手段更为成熟，采用随机生成 UUIDv4 的方式，极大地增加了流量特征的关联难度。
类似攻击近年来明显增加，这表明攻击者正在从暴力破解转向利用协议逻辑漏洞进行更精细化的侦察，以降低被发现的概率。
安全建议与 Solar 经验
针对此类威胁，我们建议企业采取以下防护措施：
- 优化日志审计策略：不要仅关注登录成功的事件。建议将“应用程序名称”为空或缺失“应用程序 ID”的登录记录纳入高优先级监控范畴，这些极有可能是异常枚举行为的信号。
- 关注异常错误码：对于 AADSTS700016 等错误代码的爆发式增长，应立即进行关联分析，这通常意味着凭据测试正在进行。
- 禁用过时认证协议：ROPC 流属于较旧的认证方式，若非业务强依赖，建议在 Entra ID 中禁用此类 legacy 认证接口。
- 强化 MFA 防护：部署抗钓鱼的强认证措施，即便凭据泄露，也能从根本上阻断攻击者的后续利用。
从应急响应的角度来看，防御的本质是缩小攻击者的“信息获取窗口”。通过对认证日志进行更深度的语义分析，可以有效识别出这些试图绕过监控的“伪装者”。
如果您想了解勒索病毒的最新发展趋势，或在实际业务中遇到类似安全事件，欢迎关注“Solar应急响应团队”。
全国热线：400-613-6816 官网：www.solarsecurity.cn / www.sierting.com