渗透攻防实战：域内 AD CS ESC1 权限边界验证、留痕分析与修复

发布于1小时前1小时

背景在已获书面授权的域内渗透测试中，Active Directory 证书服务（AD CS）经常成为普通域用户跨越权限边界的入口。本文聚焦 ESC1 类证书模板误配置：低权限主体拥有注册权限，模板允许申请者在证书主题或 SAN 中提供身份，同时证书可用于客户端身份验证。测试目标不是签发高权限身份的证书，而是通过只读枚举、普通用户自证书申请和日志核对，确认攻击链是否成立，并给出可复核的修复方案。以下步骤仅适用于明确授权的测试环境。生产环境验证应设置变更窗口，不申请管理员身份、不导出他人私钥，也不执行持久化操作。问题定位ESC1 是否成立不能只看某一个模板属性，需要同时核对四个条件：企业 CA 正在发布该模板；低权限用户或其所属组具有 Enroll 或 Autoenroll 权限；模板允许申请者提供主题信息；扩展密钥用法包含客户端身份验证、智能卡登录或其他可用于域认证的用途。检查项高风险表现常见误判模板发布状态模板已挂载到在线企业 CA目录中存在模板，但没有 CA 发布注册权限Authenticated Users、Domain Users 等可注册只有 Read 权限，不具备 Enroll主题来源CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 已启用主题完全由 AD 构建认证用途含 Client Authentication 或 Smart Card Logon仅 Server Authentication 或代码签名审批保护无经理审批、无授权签名申请必须人工审批，链路不能直接闭合技术分析证书模板对象位于 Configuration 分区。关键属性包括 msPKI-Certificate-Name-Flag、pKIExtendedKeyUsage、msPKI-Enrollment-Flag，以及对象 ACL。常见风险位 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 的十六进制值为 0x00000001。仅发现该位并不足以定性，还必须把模板 ACL、CA 发布关系和 EKU 一起纳入证据。权限边界的本质是：CA 信任模板策略，模板又允许低权限申请者声明可认证身份。如果缺少审批或授权签名，申请者提交的 SAN 可能进入最终证书。渗透测试应停在最小化证明阶段：使用测试账号申请代表其自身的证书，证明模板确实可注册；对于任意 SAN 能力，优先依据模板配置和 CA 审计日志形成证据，不要冒充高权限账户。操作步骤第一步，从域成员主机确认企业 CA 和已发布模板。certutil 属于系统自带工具，适合在限制第三方工具的环境中做基础核验。whoami /user /groups
certutil -config - -ping
certutil -CATemplates
certutil -v -template SuspectTemplate第二步，在具备 RSAT ActiveDirectory 模块的管理终端读取模板属性。以下命令为只读操作；应保存执行时间、测试账号 SID、CA 名称和模板对象 DN，便于报告复核。Import-Module ActiveDirectory
$base = (Get-ADRootDSE).ConfigurationNamingContext
$dn = "CN=SuspectTemplate,CN=Certificate Templates,CN=Public Key Services,CN=Services,$base"
$t = Get-ADObject -Identity $dn -Properties `
displayName,msPKI-Certificate-Name-Flag,msPKI-Enrollment-Flag,
pKIExtendedKeyUsage,nTSecurityDescriptor

$t | Select-Object displayName,
msPKI-Certificate-Name-Flag,
msPKI-Enrollment-Flag,
pKIExtendedKeyUsage

# 检查是否允许申请者提供 Subject/SAN
(($t.'msPKI-Certificate-Name-Flag' -band 0x1) -ne 0)

# 展开 ACL，重点核对低权限组的 Enroll/Autoenroll 扩展权
(Get-Acl ("AD:\" + $dn)).Access |
Select-Object IdentityReference,ActiveDirectoryRights,
ObjectType,AccessControlType,IsInherited |
Format-Table -AutoSize模板注册扩展权通常通过对象特定 GUID 表示，不能仅凭 ActiveDirectoryRights 中出现 ExtendedRight 就下结论。应在实验室或管理基线中解析 GUID，并与“Enroll”“Autoenroll”控制访问权对应；同时展开嵌套组，确认测试账号是否实际继承该权限。第三步，进行最小化申请验证。建议使用测试账号自身的 UPN，只验证模板是否接受申请以及 CA 是否签发，不填写管理员或其他用户标识。INF 文件中的 Subject 与 UPN 应替换为测试账号真实值。[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=pt-user"
KeyLength = 2048
KeySpec = 1
Exportable = FALSE
MachineKeySet = FALSE
RequestType = PKCS10
HashAlgorithm = sha256

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "[email protected]"

[RequestAttributes]
CertificateTemplate = SuspectTemplatecertreq -new esc1-safe.inf esc1-safe.req
certreq -submit -config "CA01.lab.example\LAB-CA" esc1-safe.req esc1-safe.cer
certutil -dump esc1-safe.cer
certreq -accept esc1-safe.cer记录 Request ID、模板名、证书序列号、Subject、SAN、EKU 和签发结果。验证结束后从当前用户证书存储中删除测试证书及私钥，并由 CA 管理员按流程吊销证书；不要在命令行或报告中保存 PFX 密码。日志留痕与排查CA 审计日志是确认申请链路的主要证据。企业 CA 开启相应审核后，可关注 Security 日志中的 4886（收到证书请求）、4887（批准并签发）、4888（拒绝）以及 4899、4900（模板加载或安全设置变更）。域控侧可结合 4768 等 Kerberos 事件排查证书认证，但是否记录及字段完整度取决于系统版本和审计策略。# 在 CA 上按测试窗口导出证书服务事件
$start = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{
LogName='Security'
Id=4886,4887,4888,4899,4900
StartTime=$start
} | Select-Object TimeCreated,Id,MachineName,Message |
Export-Csv .\adcs-audit.csv -NoTypeInformation -Encoding UTF8

# 核对 CA 数据库中的请求，RequestID 替换为实际值
certutil -view -restrict "RequestID=1234" \
-out "RequestID,RequesterName,CertificateTemplate,CommonName,NotBefore,NotAfter,SerialNumber,Disposition"排查时不要只搜索 Administrator。更有效的方法是建立基线：统计每个模板的申请者、SAN、签发量和时间分布，重点关注普通账号申请高价值认证模板、SAN 与申请者目录属性不一致、短时间多次申请、非管理终端直接访问 CA，以及模板 ACL 或标志位在申请前后发生变化。风险判定严重：模板已发布，普通域用户可注册，允许自定义主题或 SAN，包含认证 EKU，且无审批或授权签名。高危：上述条件基本满足，但受限于特定业务组；需要结合组成员规模和可控账号情况判断。中危：模板配置危险但未被任何在线 CA 发布，或申请必须经过可靠的人工审批。仍应修复，避免后续误发布。低风险或误报：只有读取权限，模板不支持身份认证，或者主题完全由目录构建且关键目录属性不可被申请者修改。修复建议从模板 ACL 中移除 Authenticated Users、Domain Users 等宽泛主体的 Enroll 和 Autoenroll，仅授予明确业务组；同时检查组嵌套。关闭“Supply in the request”，改由 Active Directory 构建 Subject 和 SAN。若业务必须自定义 SAN，应拆分专用模板并限制注册主体。删除不必要的 Client Authentication、Smart Card Logon、Any Purpose EKU；服务器证书模板不要混入用户认证用途。对高价值模板启用经理审批或授权签名，限制有效期和续订周期，并确保私钥不可导出。临时止血时，可先从 CA 取消发布风险模板；不要直接删除模板对象，以免影响取证和依赖关系确认。吊销测试及异常证书，发布新的 CRL；若怀疑 CA 私钥泄露，应按 CA 灾难恢复流程处理，不能只吊销终端证书。启用证书服务审核，集中采集 CA Security 日志，并对 4887 与申请者、模板、SAN 建立关联告警。修复后应重复三类验证：低权限账号不再拥有注册权；模板不再接受自定义身份；历史签发证书已完成吊销和 CRL 发布。仅修改模板但不处理已签发证书，风险并未真正闭环。总结AD CS 渗透测试的关键不是跑出一个工具标签，而是证明“可注册主体、模板标志、认证 EKU、CA 发布状态、审批控制”能否组成完整权限提升链路。采用只读枚举、本人身份最小申请、CA 日志交叉验证的方式，可以在不冒充高权限账号的前提下形成充分证据。最终报告应同时给出对象 DN、ACL 主体、Request ID、证书序列号、事件时间线和复测结果，保证问题可定位、可修复、可验收。

1小时前1小时

这个场景建议把“可利用”与“越权成功”拆开验证。ESC1 不能只看模板启用了 ENROLLEE_SUPPLIES_SUBJECT，至少还要同时确认：低权限主体有注册权、模板允许客户端认证类 EKU、审批和授权签名未启用、模板已发布到 CA，并且 CA/DC 当前证书映射策略允许该身份映射。

先在只读条件下固化模板与 CA 配置，便于复测前后对比：

certutil -config "CA01.contoso.local\Contoso-CA" -catemplates
certutil -v -template > C:\Temp\adcs-template-baseline.txt
certutil -config "CA01.contoso.local\Contoso-CA" -getreg CA\AuditFilter

# 有 PSPKI 模块时重点查看模板标志、EKU、审批要求和 ACL
Get-CertificateTemplate | Select Name,DisplayName,EnrollmentFlags,SubjectNameFlags,ExtendedKeyUsage
Get-CertificateTemplateAcl -Name "目标模板" | Format-List

权限边界测试不要直接使用域管身份作为目标。更稳妥的做法是创建无特权测试账号和专用测试模板，只验证请求中加入“与申请者不同的 UPN”时，CA 是否仍签发；证书私钥设为不可导出，测试结束后立即吊销并发布新 CRL。这样能证明边界问题，同时避免留下可复用的高权限凭据。

留痕方面，CA 上建议开启“请求与签发证书”审计，并同时核对 CA 数据库，不能只依赖客户端操作记录：

# 本地安全策略中同时启用“证书服务”成功/失败审计
certutil -setreg CA\AuditFilter 127
Restart-Service CertSvc

# 查询近期申请，重点关联 RequesterName、UPN/SAN、模板和序列号
certutil -view -restrict "Disposition=20" -out "RequestID,RequesterName,CertificateTemplate,CommonName,NotBefore,SerialNumber"

重点关注 CA 安全日志 4886（收到申请）、4887（签发）、4888（拒绝）和 4890（证书服务设置变更）。检测逻辑应比较“申请者账号”与证书 SAN 中的 UPN：两者不一致，且模板具备客户端认证/智能卡登录用途时，优先级应拉高。随后在域控侧关联同一时间窗的 4768，确认是否发生证书预认证；如果环境启用了强证书绑定相关审计，也要检查 Kdcsvc 的 39/40/41 映射告警。

修复时建议按以下顺序处理，避免只改一个标志后仍可绕过：

从模板 ACL 中移除 Authenticated Users、Domain Users 等宽泛主体的 Enroll/Autoenroll，仅授权明确业务组。
非必要关闭“申请者提供主题名称”，由 AD 属性构造 Subject/SAN。
确需自定义 SAN 的模板，启用 CA 管理员审批或授权签名，并与高权限登录用途隔离。
移除不必要的 Client Authentication、Smart Card Logon、PKINIT Client Authentication 等 EKU。
检查 CA 上是否启用了允许请求属性写入 SAN 的全局配置；不要把关闭模板标志当成唯一修复。
对已经签发的异常证书执行吊销、发布 CRL，并排查对应账号在签发后产生的 TGT、远程登录和目录对象修改。

最后要注意，微软强化证书映射后，某些旧式 ESC1 路径可能因强绑定策略而失败，但这不等于模板安全。模板 ACL、SAN 控制和 EKU 仍应修正，并分别在“修复前、模板下线后、CRL 发布后”做三次验证，保留 RequestID、证书序列号和相关事件时间线作为闭环证据。