国际威胁情报动态：AD CS 证书模板权限边界滥用的授权验证与日志排查

背景

近期多份国际威胁情报和事件响应报告持续提到：攻击者取得域内普通账号后，会优先检查 Active Directory Certificate Services（AD CS）配置，通过存在缺陷的证书模板扩大权限。与传统口令喷洒相比，这类链路可能不触发明显的失败登录告警，签发的证书还可能在账号密码重置后继续有效，因此逐渐成为内网攻防中的重点排查项。

本文聚焦常见的 ESC1 类配置问题：低权限主体具备注册权限，模板允许申请者提供主题信息，同时证书用途支持客户端身份认证。所有操作仅适用于已授权的测试环境，验证目标是确认权限边界和审计能力，不进行域管身份冒用或持久化。

问题定位

判断模板是否存在可利用的权限组合，不能只看模板名称或单个配置项。至少需要同时检查以下条件：

• 企业 CA 正在发布该模板，模板并非仅存在于目录中。
• Domain Users、Authenticated Users 或其他低权限组拥有 Enroll 或 Autoenroll 权限。
• 模板启用了“申请者在请求中提供主题”，对应标志通常包含 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT。
• 扩展密钥用途包含 Client Authentication、Smart Card Logon，或模板未限制 EKU。
• 未启用经理审批，且不要求授权签名。
• CA 允许基于该模板签发证书，证书链可被域控制器信任。

其中任意一项单独出现都不一定构成完整风险。新闻或扫描结果中常见的误报，是只发现“允许提供主题”便直接判定可提权，却没有核对注册 ACL、模板发布状态和 EKU。

授权环境中的验证步骤

建议使用专门创建的普通域账号进行最小化验证，并提前记录测试时间、源地址和工单编号。首先确认当前账号已有 Kerberos 票据，再执行只读枚举：

klist

certipy find -k -no-pass \
  -dc-ip 10.20.0.10 \
  -target dc01.corp.example \
  -enabled -vulnerable -stdout

certutil -config - -ping
certutil -v -template CorpUser

输出中应重点核对 Certificate Name Flag、Enrollment Rights、Extended Key Usage、Authorized Signatures Required 和 Enrollment Agent Restrictions。不要仅依赖工具给出的 ESC 编号，应回到 AD 对象 ACL 和 CA 发布列表进行复核。

模板对象通常位于配置分区：

CN=CorpUser,CN=Certificate Templates,CN=Public Key Services,
CN=Services,CN=Configuration,DC=corp,DC=example

可在装有 ActiveDirectory 模块的管理终端上读取关键属性：

$base = (Get-ADRootDSE).configurationNamingContext
$dn = "CN=CorpUser,CN=Certificate Templates,CN=Public Key Services,CN=Services,$base"

Get-ADObject -Identity $dn -Properties \
  msPKI-Certificate-Name-Flag,
  msPKI-Enrollment-Flag,
  msPKI-RA-Signature,
  pKIExtendedKeyUsage,
  nTSecurityDescriptor |
Select-Object Name,
  msPKI-Certificate-Name-Flag,
  msPKI-Enrollment-Flag,
  msPKI-RA-Signature,
  pKIExtendedKeyUsage

ACL 建议通过 certtmpl.msc 的 Security 页、ADSI Edit，或经过审计的目录查询工具交叉确认。重点关注低权限组是否具有 Extended Right 中的 Enroll，而不只是对象的读取权限。

最小化漏洞验证

生产环境不建议直接请求高权限身份的证书。较安全的验证方式是复制同等配置到隔离模板，或由 CA 管理员临时创建无特权测试模板，再使用测试账号提交一张主题与账号不一致、但不对应真实高权限主体的证书请求。若 CA 在无审批条件下接受了申请者提供的身份信息，即可证明边界缺陷。

若业务要求必须在原模板上验证，应设置维护窗口，由 CA 管理员实时监控签发队列；证书签发后立即记录序列号并吊销，随后发布新的 CRL。验证到“可签发不受约束的身份字段”即可停止，不应继续进行域控制器认证或权限提升。

日志留痕与事件关联

CA 审计需要事先启用，否则事后可能只剩 CA 数据库和 Web Enrollment/IIS 访问记录。可先检查并开启证书服务审计：

certutil -getreg CA\AuditFilter
certutil -setreg CA\AuditFilter 127
net stop certsvc
net start certsvc

auditpol /get /subcategory:"Certification Services"
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

变更审计策略和重启证书服务会影响生产系统，应纳入变更流程。不同 Windows 版本和语言环境中的子类别名称可能不同，可先执行 auditpol /list /subcategory:* 查询实际名称。

可按测试时间窗口快速筛选 CA 安全日志：

$start = (Get-Date).AddHours(-4)
Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4886,4887,4890
  StartTime = $start
} | Select-Object TimeCreated, Id, MachineName, Message |
Export-Csv .\adcs-audit.csv -NoTypeInformation -Encoding UTF8

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

实际调查时，应以 Request ID 将 4886、4887 和 CA 数据库记录串联，再把 RequesterName、源主机登录事件和域控认证日志放到同一时间线。仅凭 4768 很难直接认定证书滥用，因为正常智能卡登录也会产生类似记录。

风险判断

如果低权限用户能够为任意身份申请客户端认证证书，风险通常为高。证书私钥一旦外泄，单纯重置账号密码不足以完成处置；只要证书仍在有效期内、信任链和映射条件未变化，认证能力可能继续存在。

还需注意模板修改和证书签发是两类证据：前者说明权限边界被改变，后者说明证书已经落地。应分别保留 AD 配置分区变更、CA 审计、证书序列号和吊销状态。

修复建议

• 从存在认证用途的模板 ACL 中移除不必要的 Domain Users、Authenticated Users 和业务大组，仅保留明确的注册组。
• 无业务必要时关闭“申请者在请求中提供主题”，改为由 Active Directory 自动构建 Subject 和 SAN。
• 对高价值模板启用经理审批或授权签名，并限制可注册主体。
• 拆分邮件加密、设备证书和用户登录模板，避免一个模板同时承担多种用途。
• 缩短高风险证书有效期，限制私钥导出，并评估是否需要硬件密钥保护。
• 对已经异常签发的证书按序列号执行吊销，发布 CRL；同时确认域控制器和依赖方能够获取最新 CRL。
• 复核其他具有写模板、写 CA 对象或修改 ACL 权限的委派账号，防止修复模板后再次被改回。
• 将 4886、4887、4890 和模板目录对象变更接入集中日志平台，并对低权限申请者、异常模板及短时间批量签发建立告警。

修复后复测

复测不能只确认扫描结果消失，应验证三个层面：低权限账号无法注册目标模板；申请者不能再提供任意 Subject/SAN；CA 日志能够完整记录被拒绝的请求。随后检查模板复制品和旧版本是否仍在发布，避免只修复了同名模板中的一个对象。

总结

AD CS 风险的核心不是某个工具给出的 ESC 标签，而是“模板配置、注册 ACL、CA 发布状态、认证用途”共同形成的权限链路。面对近期威胁情报中频繁出现的证书滥用，应采用最小化授权验证、请求 ID 关联和证书生命周期处置，而不是只做一次扫描或重置账号密码。修复完成后，还要确认异常证书已经吊销、CRL 已发布、相关模板和委派权限均已复核。

这类问题建议把“模板权限”“模板配置”“CA 实际签发”分开验证。只看模板 ACL 不够：账户可能通过嵌套组获得 Enroll 权限，也可能模板已存在风险配置，但并未发布到任何 CA。

1. 先固化模板配置和 ACL

certutil -v -template "模板显示名"
dsacls "CN=模板短名,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com"

重点核对以下组合：

• 低权限主体是否通过直接授权、嵌套组或组迁移获得 Enroll/Autoenroll；
• mspki-certificate-name-flag 是否允许请求者提供 Subject 或 SAN；
• EKU 是否包含 Client Authentication、Smart Card Logon，或处于 Any Purpose/无 EKU 状态；
• 是否关闭经理审批、授权签名数量是否为 0；
• 模板对象的 WriteDACL、WriteOwner、GenericWrite 是否下放给非 PKI 管理主体。

还要确认模板是否真的发布：

certutil -config "CA主机\CA名称" -catemplates

2. 授权验证时使用专门的低权限测试账户

不要直接用管理员身份测试，否则容易掩盖 ACL 问题。先确认该账户的有效组成员关系，再提交普通请求，并记录返回的 Request ID：

whoami /user
whoami /groups
certreq -submit -config "CA主机\CA名称" -attrib "CertificateTemplate:模板短名" request.req

如果要验证“请求者可控 SAN/UPN”这一边界，应使用隔离测试账户和虚构标识，避免填入真实管理员 UPN。验证结果以 CA 最终签发证书中的 Subject、SAN、EKU 为准，不能只看请求文件。

3. 日志侧建议按 Request ID 串联

CA 的 Security 日志重点关注：

• 4886：收到证书请求；
• 4887：证书获批并签发；
• 4888：请求被拒绝；
• 4889：请求进入待处理；
• 4898：CA 加载证书模板，可用于确认模板在相关时间点是否生效。

可直接从 CA 数据库复核单个请求，避免事件日志轮转后丢失上下文：

certutil -view -restrict "RequestID=123" -out "RequestID,RequesterName,RequestType,CertificateTemplate,Disposition,NotBefore,NotAfter,SerialNumber"

模板权限或属性被修改时，证据通常在域控而不是 CA。对 Configuration 分区开启目录服务对象变更审计，并围绕模板对象 DN 查询 5136；ACL 访问审计可结合 4662。重点保留修改者 SID、属性名、旧值/新值和对应的 Logon ID。

auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable

Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 5136
  StartTime = (Get-Date).AddDays(-7)
} | Where-Object {
  $_.Message -like '*CN=Certificate Templates*'
} | Select-Object TimeCreated, Id, Message

CA 审计未开启时，可以先检查并在变更窗口内启用；修改后需要重启证书服务：

certutil -getreg CA\AuditFilter
certutil -setreg CA\AuditFilter 127
net stop certsvc
net start certsvc

4. 不要只查“异常签发”，还要追后续认证

如果已经发现可疑证书，应提取序列号、颁发者、模板和有效期，再关联域控上的 4768、4771。新版系统的 Kerberos 事件可能包含证书颁发者、序列号或指纹；同时检查同一账户在证书签发后是否从新来源地址申请 TGT。若相关字段缺失，可结合 KDC Operational、CA 数据库和终端 CAPI2 Operational 日志补齐。

处置时不建议只把模板下架。应同时撤销已签发证书、发布新 CRL、修复模板 ACL/属性，并检查是否存在同类复制模板。否则已经签出的认证证书在有效期内仍可能继续使用。