先说个误区：不少做域渗透的人把 AD CS（Active Directory Certificate Services）当成纯运维的地盘，装服务器时顺带勾上的角色，发发证书而已，跟提权不沾边。实际情况是反着来的：它的配置面在域内数一数二，历史默认配置里藏着成片的提权入口。SpecterOps 在 2021 年的 Certified Pre-Owned 研究里把这些错配编号成 ESC1 到 ESC8，普通域用户踩中任意一类，都有机会一路走到域控。域渗透预控基础系列第三篇，前两篇的 Kerberoasting 和 DCSync 打的都是凭据的主意，这篇换一条更安静的路：让企业自己的 CA 把钥匙签出来。

内网渗透打到中段，我碰过最磨人的局面，是拿到了权限却不知道往哪使。一台普通域成员机器的立足点，BloodHound 跑完，主路径看着全断：服务账号密码二十多位，离线爆破没有指望；委派配置收得紧，ACL 里也没有一眼能 abuse 的边。走到这一步，很多人开始死磕域控本身，翻版本、翻历史漏洞、翻 445 端口上的服务。

我头一回陷进这个局面时也是这么干的，直到在一台机器上卡了很久才回头。nmap 的结果里有一台开着 135 和 443、主机名带着 CA 字样的服务器，我当时直接跳过了，心里给它归的类是运维资产，下一个。后来翻 Certified Pre-Owned 白皮书，越翻越不对劲：那台被我跳过的机器，是整个域的身份签发机关，域控无条件信任它签出的任何一张证书。绕开金库去撬旁边发钥匙的窗口，而发钥匙的窗口不上锁，有问题的是这个顺序，我觉得。

这篇就把这条路线完整过一遍：AD CS 为什么能当跳板，八类错配各自长什么样，一条完整的攻击路径怎么走，以及站在防守侧怎么抢在攻击者前面把自己域扫一遍。范围不局限那八类编号，2026 年的清单已经排到 ESC17，但根基还是 2021 年那八条，从0到1，先把这八条吃透。

立足点之后的下一站：那台没人盯的 CA 服务器

先把 AD CS 的定位说清，才知道它凭什么当跳板。它是 Windows 域自带的 PKI 体系，企业 CA 给用户、机器、服务发证书，用途从智能卡登录、802.1X、Wi-Fi 认证到文件加密、LDAPS、代码签名，一路铺开。企业装它不是为了安全，是为了业务：内网上 802.1X 要证书，邮件网关要签信，LDAP 走 SSL 也要证书，于是成规模的域基本都装了。SpecterOps 的原话是 widely deployed，按这几年过内网的经验，企业域里见到它的概率接近必然。一个佐证是 BloodHound 4.x 之后干脆把 AD CS 的数据收集做成了原生功能，采集器默认就拉证书模板和 CA 对象，工具作者用脚投票：不值得收的数据不会进默认配置，进默认配置说明十个域里九个有。

真正要命的机制只有一条：Kerberos 认证书。PKINIT 扩展允许拿证书做 Kerberos 预认证，KDC 收到证书后，按证书 SAN（Subject Alternative Name）里的 UPN 映射身份。换句话说，谁手里有一张写着 administrator 的证书，谁就能以 administrator 的身份拿到 TGT，全程不需要密码；密码改了也照用，证书不会因为密码轮换而作废。攻击面在这一刻就定了型：攻击者不需要偷凭据，只需要让 CA 按正常流程签一张"你说是谁就是谁"的证书出来。这套逻辑信任的是模板配置而不是请求者本人，现在回头看挺拧巴，但 PKI 的设计初衷里没有"请求者可能是攻击者"这一条。

配置面为什么大：证书模板自己就带七八个安全相关属性，EKU、SAN 标志、注册权限、审批要求、发布范围；CA 层还有注册权限、管理角色、注册策略标志；再往外一层是 Web 注册端点的认证方式。每个旋钮都跟安全挂钩，而管理员面对的是几十个模板乘以上面这一串选项。白皮书里有句评语我印象很深，大意是管理员拿了一把开着保险栓的枪二十年，没人教过怎么安全地端着它。2021 年 6 月，Will Schroeder（@harmj0y）和 Lee Christelsen 把这套体系的安全问题系统化成 Certified Pre-Owned 白皮书，当年在 Black Hat USA 讲的就是它，ESC1 到 ESC8 的编号从此成了行业通用语。同年 10 月，Oliver Lyak（ly4k）开源了 Certipy，把整套研究变成一条命令就能跑的工具链，到 2026 年已经覆盖 ESC1 到 ESC17，错配清单本身也在长。

八类错配全景：四个层面，各有各的病

清单在长，根基还是那八类。编号看着唬人，按出问题的层面分组就清楚了：模板自己配错（ESC1、ESC2、ESC3），权限给错（ESC4、ESC5、ESC7），CA 配置开错（ESC6），网络端点收错认证（ESC8）。先放全景表，后面按组拆。

模板类三条的病根都是模板太信任请求者。ESC1 是原型：模板的 mspki-certificate-name-flag 属性里带 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT 标志，控制台里对应证书模板 Subject Name 标签下的 Supply in the request 选项，开了它，证书主题就由请求者自己填；再配上认证类 EKU（Client Authentication、Smart Card Logon、PKINIT Client Authentication、Any Purpose 任选其一）、注册权限落到 Domain Users、不要求管理员审批、不要求授权签名，四个条件凑齐，普通用户就能申请一张 SAN 写着域管的证书。这种模板很少是管理员凭空写的，多半是复制 WebServer 或 SubCA 这类自带"请求者填主题"的模板、再补一个客户端认证 EKU 改出来的，改的人未必知道前一个标志意味着什么。ESC2 更省事：模板 EKU 是 Any Purpose（OID 2.5.29.37.0）或者压根不设，证书用途不设限，拿去认证自然也行。这两条在利用上跟 ESC1 只差参数：ESC2 换一个任意用途模板照样用 certipy req 提交，SAN 想写谁写谁，认证时 KDC 不挑证书的用途标签；这也是为什么 ESC2 的检出经常比 ESC1 还多——Any Purpose 看起来是个"通用方便"的设置，管理员勾它的时候想不到等同于"这张证书可以当任何人的身份证用"。

ESC3 换了个思路，走注册代理：模板带 Certificate Request Agent EKU（OID 1.3.6.1.4.1.311.20.1.1），攻击者先在这类模板上给自己申请一张代理证书，再拿着它替域管走 on-behalf-of 流程申请第二张证书，Certipy 里对应 req 命令的 -on-behalf-of 参数，域内没限制注册代理的代申请范围时，两段加起来还是合法操作。跟 ESC1 相比它绕了一点路，好处是不依赖 SAN 标志，模板面子上看是正常的，枚举工具不标 ESC1 的模板照样能打穿。这也是八类错配共同的味道：每一段单看都有正当的业务理由，串起来就是提权。

权限类三条的病根是该锁死的对象没锁死。ESC4 是攻击者对模板对象本身握着写权限，WriteOwner、WriteDacl、WriteProperty 任意一条都够用：不求管理员配错，自己把一个正常模板改成 ESC1

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）