近期 AD CS Web Enrollment 遭 NTLM Relay 利用的攻防趋势与核查指南

背景：从漏洞利用转向身份基础设施

近期多起国际威胁情报与公开事件复盘显示，攻击者进入 Windows 域后，越来越倾向于利用 Active Directory Certificate Services（AD CS）建立持久权限。一个仍然常见的链路是：诱导域内主机向攻击端发起 NTLM 认证，再将认证转发到未启用 HTTPS 或 Extended Protection for Authentication（EPA）的 AD CS Web Enrollment 接口，最终申请可用于域身份认证的证书。

这类事件不一定依赖新的 CVE，问题通常来自历史组件、默认兼容配置和权限边界叠加。对授权渗透测试而言，重点不是直接申请高权限证书，而是确认中继条件是否同时成立、记录可验证证据，并给出不会破坏生产认证链的修复顺序。

以下操作仅用于已获授权的域环境核查。生产环境不建议直接执行强制认证、证书申请或模板修改；验证阶段应使用隔离测试账号，并提前约定停止条件。

问题定位：先确认攻击面是否存在

该链路通常需要满足三个条件：域内存在启用 Web Enrollment 的企业 CA；证书站点接受 NTLM；站点未强制 HTTPS 或未启用 EPA。若攻击者还能影响机器账户或高权限账户发起认证，风险会进一步扩大。

在 CA 服务器上，可先用只读命令确认角色、IIS 站点和 CA 配置。不要仅凭 80 端口开放就判定可利用，应同时检查 certsrv 虚拟目录的认证与 TLS 设置。

# PowerShell：确认 AD CS Web Enrollment 角色
Get-WindowsFeature ADCS-Web-Enrollment, Web-Windows-Auth |
  Format-Table Name, InstallState

# 查看企业 CA，不发起证书申请
certutil.exe -config - -ping
certutil.exe -getreg CA\AuditFilter

# 查看 IIS 中 certsrv 的认证与 TLS 配置
& $env:windir\system32\inetsrv\appcmd.exe list config "Default Web Site/certsrv" /section:system.webServer/security/authentication/windowsAuthentication
& $env:windir\system32\inetsrv\appcmd.exe list config "Default Web Site/certsrv" /section:system.webServer/security/access

核查结果中需要关注：Windows Authentication 是否启用、providers 是否包含 NTLM、extendedProtection.tokenChecking 是否为 None，以及 sslFlags 是否未包含 Ssl。若 CA Web Enrollment 已卸载，或 certsrv 只允许 Kerberos 且已启用 EPA，则这条具体路径通常不成立，但仍需继续审计其他证书注册接口。

技术分析：为何权限边界会被绕过

NTLM Relay 的核心不是破解口令，而是把受害主机提交的挑战响应转发给另一个接受 NTLM 的服务。若 certsrv 接受该会话，CA 会按照被中继身份拥有的模板权限处理申请。证书一旦包含适当的客户端身份验证用途，就可能被用于后续域认证；即使账户密码随后修改，未吊销且仍在有效期内的证书也可能继续有效。

因此，风险评估不能只看“是否能访问 certsrv”，还要联动检查模板边界。授权测试中建议只做模板配置审计，不实际签发高权限证书。

# 在具备 RSAT/AD CS 管理工具的审计主机上导出模板信息
certutil.exe -v -template > C:\Temp\adcs-templates.txt

# 重点检索认证用途、注册权限及主体提供方式
Select-String -Path C:\Temp\adcs-templates.txt `
  -Pattern "Client Authentication|Smart Card Logon|Enrollment Rights|ENROLLEE_SUPPLIES_SUBJECT"

审计时应重点识别：低权限主体拥有 Enroll 或 Autoenroll；模板包含 Client Authentication、Smart Card Logon 等认证 EKU；申请者可自行提供 Subject 或 SAN；审批、授权签名及 RA 限制缺失。任何单项都不一定直接构成完整攻击链，需要结合 CA 发布状态与 Web Enrollment 配置判断。

操作步骤：以最小影响完成授权验证

• 范围确认：明确 CA 主机、测试账号、测试时段和禁止操作，尤其禁止对域控、集群节点和关键业务服务器触发认证。
• 被动枚举：只读获取 CA、已发布模板、IIS 认证方式、HTTPS 和 EPA 状态。
• 条件判定：验证 certsrv 是否接受 NTLM，但不提交证书申请。生产环境可通过 IIS 配置和日志完成证据闭环，无需进行中继。
• 边界核查：确认低权限用户或机器账户可注册哪些认证模板，并检查模板的 Subject、SAN、EKU、审批和签名要求。
• 留痕复核：关联 CA 审计日志、IIS 日志、Windows 登录日志和测试源地址，确认监控能否发现异常申请。
• 清理：删除测试导出文件；若变更过测试配置，应按变更单回滚并复核站点状态。

日志留痕与事件排查

可以先用事件日志做小时间窗筛选，再与 IIS 日志交叉验证。不要单独以 4887 告警，因为正常自动注册也会大量产生签发事件；更有效的规则是“敏感模板 + 异常来源地址 + NTLM 网络登录 + 非常规时间”。

# 查询最近 24 小时 CA 相关事件
$start = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4886,4887,4888
  StartTime=$start
} | Select-Object TimeCreated, Id, Message |
  Export-Csv C:\Temp\ca-events.csv -NoTypeInformation -Encoding UTF8

# 查询 CA 主机上的 NTLM 网络登录
Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4624
  StartTime=$start
} | Where-Object {
  $_.Message -match 'Logon Type:\s+3' -and
  $_.Message -match 'Authentication Package:\s+NTLM'
} | Select-Object TimeCreated, Message

风险判断与修复建议

修复应优先消除中继条件，再收敛模板权限。直接全域禁用 NTLM 可能造成旧业务中断，建议先审计后分阶段实施。

• 不需要 Web Enrollment 时直接卸载该角色，并确认 IIS 中遗留的 certsrv 应用已移除。
• 必须保留时，为 certsrv 强制 HTTPS，部署受信任服务器证书，并启用 EPA。变更前先验证代理、负载均衡和旧客户端兼容性。
• 通过组策略启用 NTLM 审计，识别依赖后逐步设置拒绝策略；同时对 SMB 启用签名，减少可被诱导和中继的入口。
• 收紧模板 Enroll 权限，移除 Domain Users、Authenticated Users 等宽泛主体；对认证类模板启用经理审批或授权签名。
• 关闭非必要的申请者自定义 Subject/SAN 能力，核对模板 EKU，避免将身份认证用途附加到普通业务证书模板。
• 启用 CA 审计并集中采集 IIS、CA 与安全日志；对异常模板签发、机器账户集中申请和 CA 上的 NTLM 登录建立关联告警。

若已确认发生异常签发，不能只修改账户密码。应根据 Request ID 和序列号吊销证书、发布新的 CRL，核查证书有效期内的域认证记录，并检查相关账户权限、持久化配置及横向移动痕迹。对 CA 私钥疑似泄露的情况，应升级为 PKI 级事件处置，评估 CA 证书更换与信任链重建。

总结

近期 AD CS 相关事件反映出一个明确趋势：攻击者更关注能跨越密码重置的身份材料，而不是单次主机控制。对于新闻动态板块，更值得持续跟踪的不是某个工具名称，而是 NTLM 使用面、证书注册接口暴露和模板权限边界的变化。授权测试应以只读核查、日志闭环和最小影响验证为主；修复则应按照“关闭不必要接口、强制 HTTPS 与 EPA、收敛模板权限、逐步限制 NTLM”的顺序推进。

这类事件核查时，建议不要只盯 CA 日志。AD CS Web Enrollment 被用于 NTLM Relay，通常要同时满足三组条件：域内存在可诱导认证的入口、IIS 接受 NTLM、证书模板允许目标主体取得可用于域认证的证书。排查也应按这三段链路展开。

1. 先确认暴露面和 IIS 认证配置

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

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

Get-WebBinding | Where-Object { $_.bindingInformation -match ':80:' } |
  Format-Table protocol,bindingInformation,itemXPath

重点检查 /certsrv/ 是否仍可通过 HTTP 访问，以及 Windows Authentication 的 provider 中是否包含 NTLM。仅把站点改到 HTTPS 不够，还需要启用 Extended Protection for Authentication（EPA），并避免 HTTP 回落。若业务允许，优先直接移除 Web Enrollment；很多环境安装后长期无人使用。

2. 检查模板是否会放大机器账户被中继后的影响

certutil -CATemplates
certutil -v -template > C:\Temp\adcs-templates.txt

关注启用了 Client Authentication、Smart Card Logon 或 PKINIT 相关 EKU，且向 Domain Computers、Domain Controllers 或宽泛主体开放 Enroll 的模板。尤其要核对模板 ACL、是否允许请求者提供 Subject/SAN、是否需要审批及授权签名。不要只依据模板显示名称判断，最终应查看模板对象的权限和标志位。

3. 日志关联要围绕“证书签发后紧接证书认证”

CA 上检查 CertificationAuthority/Operational，并结合 CA 数据库中的请求者、模板、序列号和时间；IIS 则检查 cs-uri-stem=/certsrv/certfnsh.asp 一类请求、POST、异常来源地址及非浏览器 User-Agent。随后在域控关联安全日志中的 Kerberos 证书预认证行为。单条 4887 并不能直接证明中继，关键是请求来源、请求者账户、模板和后续认证是否形成时间链。

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4886,4887,4888,4890} |
  Select-Object TimeCreated,Id,MachineName,Message

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768} |
  Where-Object { $_.Message -match 'Certificate|Pre-Authentication Type:\s+16' } |
  Select-Object TimeCreated,MachineName,Message

Get-ChildItem 'C:\inetpub\logs\LogFiles' -Recurse -Filter *.log |
  Select-String '/certsrv/|certfnsh\.asp'

不同 Windows 版本和审计策略下字段会有差异，建议先在测试环境生成一次正常证书申请，确认本环境的事件格式和基线。若 CA 审计事件缺失，可在 CA 属性的 Auditing 中启用“证书服务的备份和还原、证书请求、CA 配置变更”等审计，并确认对象访问审计策略已生效。

4. 修复顺序

1. 不用 Web Enrollment：卸载角色服务，并确认站点、虚拟目录和旧绑定一并清理。
2. 必须使用：仅开放 HTTPS，禁用 HTTP，启用 EPA（优先 Required），测试通过后移除 NTLM provider，限制访问源网段。
3. 收紧高价值模板的 Enroll/Autoenroll 权限，移除不必要的认证 EKU和请求者自定义 Subject/SAN，必要时增加审批或授权签名。
4. 同步降低强制认证面：启用 SMB signing，评估并推进 LDAP signing/channel binding，停用不必要的 WebClient，限制 EFSRPC、打印服务等不需要的远程接口。

如果已经发现可疑签发，不要只删除 IIS 日志或停站点。应先导出 CA 数据库与 IIS/域控日志，记录证书序列号、Thumbprint、模板和请求者，再吊销证书并发布新的 CRL；同时按受影响账户级别处置凭据。若涉及域控机器账户，需要按域级事件处理，因为攻击者可能已经借证书认证取得持久访问。