威胁情报动态】NTLM Relay 转向 AD CS：近期内网攻击链的验证、日志关联与加固

背景：近期内网攻击链为何重新关注 AD CS

近期公开威胁情报和多起企业应急案例显示，攻击者对 NTLM Relay 的利用重点正从传统 SMB 横向移动，转向 Active Directory Certificate Services（AD CS）证书服务。常见链路是：诱导域内高权限主机发起 NTLM 认证，将认证转发到 AD CS Web Enrollment 或 Certificate Enrollment Web Service，申请可用于客户端身份认证的证书，再通过证书换取 Kerberos 票据。

这类链路本身通常不依赖新的内存破坏漏洞，而是叠加利用协议兼容配置、证书模板权限和审计缺口。授权渗透测试中，重点不应只是证明“能够拿到证书”，还要确认触发条件、权限边界、日志留痕以及修复后的阻断效果。

本文仅讨论已获授权环境中的只读排查、受控验证与蓝队检测，不提供针对互联网目标的扫描或未授权利用方法。

问题定位：先确认攻击链是否具备成立条件

典型的 AD CS Relay 风险通常需要多个条件同时成立：

• 域内存在企业 CA，并启用了 Web Enrollment 或其他接受 Windows 集成认证的证书申请端点。
• 相关 IIS 站点允许 NTLM，且未强制 Extended Protection for Authentication（EPA）。
• 入口认证协议可被转发，例如部分 SMB 服务未强制签名，或存在可被诱导的 HTTP、RPC 认证路径。
• CA 发布了允许目标计算机或用户注册的证书模板，模板包含 Client Authentication、Smart Card Logon 等可用于身份认证的 EKU。
• 攻击者已经位于能够接收或转发认证流量的内网位置。

因此，发现 Web Enrollment 并不等于可以直接定性为可利用。应同时检查 IIS 身份认证、EPA、模板 EKU、注册权限以及入口协议约束。

授权环境中的只读排查

建议先在 CA 服务器和域管理工作站上执行只读命令，建立证书服务资产清单。以下命令不会申请证书，也不会修改模板：

REM 查询企业 CA 与已发布模板
certutil -config - -ping
certutil -CATemplates

REM 查看本机企业 CA 配置
certutil -getreg CA

REM 检查 CA 审计过滤器
certutil -getreg CA\AuditFilter

REM 检查 IIS 是否安装证书注册相关组件
%windir%\system32\inetsrv\appcmd.exe list app
%windir%\system32\inetsrv\appcmd.exe list config "Default Web Site/CertSrv" /section:system.webServer/security/authentication/windowsAuthentication

REM 检查 SMB 服务端是否要求签名
powershell -NoProfile -Command "Get-SmbServerConfiguration | Select EnableSecuritySignature,RequireSecuritySignature"

REM 检查 SMB 客户端签名策略
powershell -NoProfile -Command "Get-SmbClientConfiguration | Select EnableSecuritySignature,RequireSecuritySignature"

如果使用 Certipy 做授权枚举，应限定到指定域和凭据，仅执行发现功能，不触发证书申请：

certipy find -u [email protected] -dc-ip 10.10.10.10 -enabled -stdout

输出中应重点核对以下字段：Enrollment Rights、Extended Key Usage、Enrollee Supplies Subject、Authentication Enabled，以及 CA Web Enrollment 状态。工具给出的 ESC8 等标签适合作为线索，不应替代人工验证。

技术分析：权限边界在哪里

最关键的边界是证书最终代表谁。如果被转发的是普通工作站账户，影响通常受该账户本身权限限制；如果是域控制器账户或高权限用户，证书可被用于获取相应主体的 Kerberos 身份，后果会明显扩大。评估报告中应区分“能够访问注册端点”“能够提交申请”“能够获得认证证书”和“能够换取高权限票据”四个层级。

日志留痕与关联分析

建议将 CA、域控制器、IIS 和网络侧日志按时间线关联。单看某一类事件容易漏判。

• CA 安全日志：事件 4886 表示收到证书申请，4887 表示签发，4888 表示拒绝。是否产生这些事件取决于 CA 审计和系统审核策略。
• 域控制器安全日志：4768 用于观察 TGT 请求。证书登录场景应关注 Pre-Authentication Type、证书信息和来源地址；不同 Windows 版本的字段展示可能不同。
• 账户登录日志：4624 中关注 Logon Type、Authentication Package、源地址及账户名。
• IIS 日志：检查对 /certsrv/certfnsh.asp、/certsrv/certnew.cer 等路径的访问，重点关注异常来源 IP、短时间连续 POST 和非管理网段访问。
• 网络日志：寻找主机被异常诱导后，对非预期内网地址发起 SMB、HTTP 或 RPC 认证的行为。

可以使用 PowerShell 快速提取 CA 相关事件，缩小调查范围：

$start = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4886,4887,4888
  StartTime = $start
} | Select-Object TimeCreated, Id, MachineName, Message |
  Export-Csv .\ca-events.csv -NoTypeInformation -Encoding UTF8

Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4768
  StartTime = $start
} | Select-Object TimeCreated, Id, MachineName, Message |
  Export-Csv .\tgt-events.csv -NoTypeInformation -Encoding UTF8

实际分析时，可使用申请者账户、证书序列号、模板名和时间窗口进行关联。一个值得优先调查的模式是：高价值机器账户在非维护时段产生证书申请，随后短时间内从另一台主机出现 4768，并且 IIS 请求源不属于 CA 管理网段。

受控验证步骤

1. 确认书面授权范围，明确允许验证的 CA、模板、测试账户和时间窗口。

2. 使用专用低权限测试账户，只读枚举 CA 与模板配置，不使用真实管理员账户触发认证。

3. 在隔离测试网段创建临时模板副本，限制注册权限到测试组，避免对生产模板直接操作。

4. 先验证 IIS 是否强制 HTTPS 和 EPA，再验证模板是否允许测试主体申请客户端认证证书。

5. 若必须进行链路级验证，应使用专用测试计算机账户，并提前通知 SOC，确保 CA、IIS、域控制器日志均已开启。

6. 验证完成后立即吊销测试证书、清理临时模板、更新 CRL，并检查测试账户是否残留票据或证书私钥。

修复建议

第一优先级：处理证书注册端点。

• 不需要 Web Enrollment 时直接卸载相关角色服务或停止发布 CertSrv 站点。
• 确需使用时强制 HTTPS，禁用 HTTP 绑定，并在 Windows Authentication 中启用 EPA。
• 将证书注册端点限制到管理网段，通过防火墙或反向代理控制来源。

第二优先级：收紧模板权限。

• 移除 Domain Users、Domain Computers 等过宽注册权限，改为专用安全组。
• 清理不必要的 Client Authentication、Smart Card Logon 等认证 EKU。
• 对高风险模板启用经理审批或授权签名，但不要把审批当作唯一防线。
• 定期检查模板 ACL，尤其关注 WriteDacl、WriteOwner、GenericAll 和模板发布权限。

第三优先级：压缩 NTLM Relay 条件。

• 在兼容性验证后，对服务器和客户端逐步强制 SMB 签名。
• 通过“Network security: Restrict NTLM”策略先审计、后限制 NTLM 使用。
• 对 LDAP 启用签名和 Channel Binding，避免风险转移到其他协议端点。
• 限制服务器不必要的出站 SMB、WebDAV 和 HTTP 访问，减少被诱导认证的机会。

第四优先级：补齐审计。

启用“证书服务审核”高级审核策略，并配置 CA 审计过滤器。修改前应记录当前值并安排维护窗口：

REM 查看现有配置
certutil -getreg CA\AuditFilter

REM 示例：启用全部 CA 审计类别，生产环境修改前应完成变更评审
certutil -setreg CA\AuditFilter 127
net stop certsvc
net start certsvc

REM 启用证书服务审核子类别
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

不同语言版本系统的审核子类别名称可能不同，可先执行 auditpol /list /subcategory:* 获取本机名称。变更后应通过一次正常测试申请确认 4886、4887 等事件能够落盘，并评估日志容量。

修复后的复测标准

• HTTP 访问 CertSrv 被拒绝或重定向后仍无法通过明文端点完成认证。
• IIS 已启用 EPA，非预期的转发认证无法被注册端点接受。
• 测试账户无法注册具有客户端认证能力的高权限模板。
• SMB 签名策略已覆盖关键服务器，且未造成旧系统业务中断。
• CA 申请、签发、拒绝事件能够被集中采集，并可与 4768、IIS 和网络日志关联。
• 已吊销验证期间产生的证书并发布新 CRL，测试模板和临时权限均已清理。

总结

近期 AD CS 相关攻击趋势的核心，不是某一个工具或单一漏洞，而是 NTLM 兼容配置、证书注册端点、模板权限和审计缺口共同构成的身份接管链。排查时应按“认证入口—转发端点—证书模板—身份兑换—日志关联”逐段确认，避免看到一个 ESC 标签就直接下结论。对生产环境而言，优先关闭不必要的注册端点、启用 HTTPS 与 EPA、收紧模板 ACL，再逐步推进 SMB 签名和 NTLM 限制，通常比单纯封禁工具特征更有效。

这条链路排查时，建议不要只盯着 CA 的证书签发日志。更有效的做法是以“异常 NTLM 入站 → CA Web Enrollment 请求 → 证书签发 → 证书登录”为时间线关联。

可以优先收集以下数据：

• CA：安全日志 4886、4887、4888，以及证书服务数据库中的 RequesterName、Template、SerialNumber、RequestID。
• CA/IIS：/certsrv/ 对应的 IIS 日志，重点看客户端 IP、URI、状态码和认证用户。
• 被诱导认证的主机：Microsoft-Windows-NTLM/Operational，关注 8001、8002、8004。
• 域控：4624、4768、4769；如果后续使用证书进行 PKINIT，4768 的证书信息和异常源地址比较关键。

CA 上可以先用证书数据库做一次回溯：

certutil -view -restrict "Disposition=20" ^
  -out "RequestID,RequesterName,CertificateTemplate,SerialNumber,NotBefore,NotAfter"

重点检查计算机账户申请的证书：申请时间是否紧邻某台服务器产生的异常 NTLM 认证、模板是否允许客户端身份验证、申请来源 IP 是否不是该计算机平时所在网段。不要仅凭“机器账户申请机器证书”判定正常，Relay 到 AD CS 时这恰好是常见外观。

如果启用了 Web Enrollment，可先确认 IIS 的 TLS、Windows 身份验证和扩展保护状态：

Import-Module WebAdministration

Get-WebConfigurationProperty `
  -PSPath 'IIS:\' `
  -Filter 'system.webServer/security/authentication/windowsAuthentication' `
  -Name 'enabled'

Get-WebConfigurationProperty `
  -PSPath 'IIS:\' `
  -Filter 'system.webServer/security/authentication/windowsAuthentication/extendedProtection' `
  -Name 'tokenChecking'

Get-WebConfigurationProperty `
  -PSPath 'IIS:\' `
  -Filter 'system.webServer/security/access' `
  -Name 'sslFlags'

加固顺序建议是：

1. 不需要 /certsrv、CES/CEP 时直接卸载或停用，而不是只做网络隐藏。
2. 必须保留时强制 HTTPS，关闭 HTTP 绑定，并将 Windows Authentication 的 Extended Protection 设为 Require。修改前要验证代理、负载均衡和旧客户端兼容性。
3. 在 CA 服务器启用“要求 SMB 签名”，LDAP 侧启用签名及 Channel Binding，减少 Relay 可用入口。
4. 审计证书模板，尤其是带 Client Authentication/Smart Card Logon EKU、低权限主体可 Enroll、允许申请者提供 Subject/SAN 的组合。
5. 逐步限制 NTLM；先开审计确认遗留依赖，不建议直接全域拒绝。

IIS 配置调整后，可以再次检查站点级配置是否实际继承到 CertSrv 应用，而不是只看服务器全局配置。存在反向代理时，还要确认 TLS 是否在 IIS 前终止；如果是，EPA 的部署方式需要单独验证，否则“已设 Require”也可能造成业务中断或保护未按预期生效。

事件关联上，建议用 RequestID/SerialNumber 固化证据链：从 4887 找到签发记录，再回查同一时间 IIS 的客户端 IP，随后检查该账户是否在数分钟内出现 4768、4624 或远程管理行为。这样比单独告警“CA 签发了机器证书”误报少很多。若确认异常，应先禁用涉事账户或隔离主机，再吊销证书并发布新 CRL；仅删除本地证书不能阻止攻击者继续使用已导出的私钥和证书。