1. 项目概述从AD CS到ESC1的攻防视角在Active Directory证书服务AD CS的攻防世界里Certipy已经从一个新兴工具变成了渗透测试人员和红队成员的必备瑞士军刀。它用Python重写了之前一些零散的PowerShell脚本把对AD CS的攻击和枚举能力整合到了一个统一的、功能强大的框架里。而ESC1作为AD CS攻击面中一个经典且极具威胁的漏洞其完整的攻击链条理解起来并不简单它涉及到证书模板的配置、客户端认证的机制、以及权限提升的路径。今天我们就来彻底拆解这条链看看攻击者是如何利用一个配置不当的证书模板从一个普通域用户摇身一变成为域管理员的。简单来说ESC1漏洞的核心在于一个被错误配置的证书模板。这个模板允许低权限用户为自己申请一个可用于客户端身份验证的证书并且这个证书的身份可以“伪装”成其他任何用户包括域管理员。当攻击者获得这样一个证书后他们就可以用它向域控制器进行Kerberos认证获取目标用户比如域管理员的票证授予票证TGT从而完全接管该用户的权限。整个过程完全在AD CS的正常业务流程之内不依赖于任何未公开的漏洞纯粹是配置缺陷导致的权限滥用因此隐蔽性极强。对于蓝队和系统管理员而言理解ESC1不仅是修复一个配置问题更是重新审视整个AD CS安全模型的关键。2. ESC1漏洞原理深度拆解证书模板的“致命组合”要理解ESC1我们必须先深入AD CS证书模板的配置逻辑。一个证书模板定义了什么用户可以申请证书、证书的用途是什么、以及证书里包含哪些信息。ESC1的成立需要几个关键条件同时满足我们可以把它们看作一个“致命组合拳”。2.1 核心漏洞条件四个必须同时满足的配置项ESC1漏洞的利用依赖于证书模板上四个特定的配置项同时被启用或配置不当。缺一不可这也是我们排查风险时的检查清单。第一客户端身份验证Client Authentication的EKU。这是证书的“用途声明”。EKUExtended Key Usage扩展密钥用法指明了这个证书能用来干什么。Client AuthenticationOID: 1.3.6.1.5.5.7.3.2是其中最关键的一个它意味着该证书可以用于向服务器证明客户端的身份在AD环境中这就是Kerberos认证的入场券。如果模板没有启用这个EKU即使拿到证书也无法用于域认证攻击链就此中断。第二允许低权限用户注册Enrollment Permissions。证书模板的访问控制列表ACL决定了谁可以申请它。默认情况下许多管理模板只允许特定安全组如Domain Admins注册。ESC1要求这个模板的“注册”权限被授予了过于宽松的主体例如Authenticated Users、Domain Users甚至Everyone。这意味着任何一个通过验证的域用户都能提交证书申请。第三无需管理者批准No Manager Approval。这是一个流程控制选项。如果启用证书申请需要经过指定的证书管理员手动批准后才能颁发。这会给攻击增加极大的不确定性。ESC1利用链要求这个选项必须被禁用使得证书的颁发是自动的、即时的攻击者可以实时获取到恶意证书。第四也是最关键的一项在主题中提供SANSubject Alternative Name。这是ESC1的灵魂所在。SAN扩展允许在证书中指定一个或多个与该证书关联的身份名称。关键配置在于“主题名称”设置中的“在请求中提供”。当管理员勾选了这一项就意味着申请者在提交证书签名请求CSR时可以自己指定SAN字段的内容。攻击者可以在此处填入任何域用户的用户主体名称UPN例如administratordomain.local。证书颁发机构CA在颁发证书时会无条件地将用户提供的SAN写入证书而不会去验证申请者是否有权“扮演”这个身份。注意这里有一个常见的误解点。很多人认为攻击者修改的是证书的“主题Subject”即CN字段。实际上在ESC1中攻击者操控的是SAN中的UPN。在Kerberos的PKINIT认证流程中KDC密钥分发中心通常由域控制器担任更优先使用SAN中的UPN来识别用户身份而不是主题中的CN。这给了攻击者更大的灵活性。2.2 权限提升的本质从证书到TGT当这四个条件齐备时攻击链就具备了启动的基础。其权限提升的本质可以概括为利用CA对SAN内容缺乏校验的缺陷获取一个以高权限用户身份声明的客户端认证证书并用该证书通过PKINIT完成Kerberos预认证从而获得目标高权限用户的TGT。这个过程完全遵循了Kerberos的PKINIT扩展协议。正常情况下用户用密码哈希进行预认证。而在PKINIT中用户使用其私钥签名的数据来证明自己拥有对应证书的私钥。KDC则用证书中的公钥验证签名并从证书中提取用户身份UPN。在ESC1场景下KDC从证书SAN中提取到的UPN是攻击者伪造的administratordomain.local因此它自然而然地认为正在认证的是域管理员于是颁发给攻击者一个域管理员的TGT。至此攻击者就成功地“成为”了域管理员。3. 利用Certipy自动化攻击链实操理论清晰后我们进入实战环节。Certipy的强大之处在于它将整个复杂的攻击流程封装成了简单的命令。下面我们一步步拆解并解释每个命令背后的操作。3.1 环境侦察与漏洞模板发现攻击的第一步是信息收集。我们需要找到域内所有的CA服务器以及它们颁发的证书模板。# 使用Certipy发现域内的CA服务器 certipy find -u userdomain.local -p Password123 -dc-ip 192.168.1.10 # 更详细地枚举指定CA服务器上的证书模板及其配置 certipy find -u userdomain.local -p Password123 -dc-ip 192.168.1.10 -ca LAB-DC-CA第一条命令会进行基本的域内CA发现。第二条命令则针对特定的CALAB-DC-CA进行深度枚举它会列出该CA上所有可用的证书模板并详细输出每个模板的配置属性。在输出结果中你需要像鹰一样寻找同时满足以下条件的模板ENROLLMENT_FLAGS包含CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT(这对应“在请求中提供SAN”)EXTENDED_KEY_USAGE包含Client Authentication权限部分 (PERMISSIONS) 显示Authenticated Users具有Enroll权限。FLAGS中不包含CT_FLAG_PEND_ALL_REQUESTS(这对应“需要管理者批准”)Certipy的输出是JSON格式非常清晰。一旦找到这样的模板记下它的名字例如VulnerableWebServer它就是我们的目标。3.2 恶意证书请求与获取确认目标模板后就可以发起攻击了。这里的关键是使用-alt参数指定我们想要冒充的用户。# 请求证书并尝试将身份伪装为域管理员 certipy req -u attackerdomain.local -p AttackerPassword -dc-ip 192.168.1.10 -ca LAB-DC-CA -template VulnerableWebServer -alt administratordomain.local这个命令的执行过程如下连接CA以attackerdomain.local的身份连接至CA服务器LAB-DC-CA。构建PKCS#10 CSRCertipy在本地生成一对RSA密钥默认2048位并创建证书签名请求。在CSR的SAN扩展中它会填入我们通过-alt参数指定的administratordomain.local。提交申请将CSR提交给CA请求基于VulnerableWebServer模板颁发证书。CA处理CA检查请求者(attacker)是否有VulnerableWebServer模板的注册权限有。检查该模板是否要求管理员批准否。然后它看到CSR请求中包含SAN并且模板配置允许请求者提供SAN于是CA使用自己的私钥对CSR进行签名生成证书。关键点CA不会验证administratordomain.local这个SAN是否与请求者身份匹配。获取证书CA将颁发的新证书.crt文件和对应的私钥.key文件返回给Certipy。Certipy会将其保存为administrator.pfx一个包含证书和私钥的PKCS#12格式文件。至此攻击者手中已经握有了一个“合法”的、声明身份为域管理员的客户端认证证书。3.3 证书认证与TGT获取有了.pfx文件下一步就是用它进行Kerberos认证换取域管理员的TGT。# 使用获取的PFX文件进行认证获取TGT certipy auth -pfx administrator.pfx -dc-ip 192.168.1.10这个命令背后的流程是标准的PKINITPKINIT AS-REQCertipy构造一个Kerberos AS-REQ认证服务请求报文。与普通请求不同它包含PA-PK-AS-REQ预认证数据其中包含了我们刚刚获得的证书。KDC验证域控制器作为KDC收到请求后提取证书验证其签名链确认为本域CA颁发检查证书有效性未过期、未被吊销并确认其包含Client AuthenticationEKU。接着KDC从证书的SAN中提取UPNadministratordomain.local。颁发TGTKDC认为域管理员administrator正在使用证书认证。它生成一个用于administrator的TGT并使用administrator在AD中存储的密钥即其密码哈希派生的密钥加密这个TGT。注意加密TGT的密钥是基于目标用户administrator的密码而不是攻击者的密码或证书公钥。响应与解密KDC将加密后的TGT放在AS-REP中返回。Certipy收到响应后由于没有administrator的密码哈希它无法直接解密TGT。但是PKINIT协议允许一种称为“Diffie-Hellman”的密钥交换机制使得KDC可以使用证书中的公钥加密一个会话密钥Certipy再用对应的私钥解密获得它。这个会话密钥用于加密回复中的其他部分。实际上Certipy和Impacket等工具利用的是更直接的方式它们直接输出从KDC响应中获取的administrator的NTLM哈希如果KDC支持较老的加密类型或TGT的Kirbi格式文件。结果输出执行上述命令后Certipy会成功输出administrator用户的NTLM哈希。这是整个攻击链的决定性成果。有了这个哈希攻击者就可以进行“传递哈希”攻击或者将其转换为Kirbi格式的TGT文件用于后续的所有Kerberos操作。3.4 权限的最终兑现获取到域管理员的哈希或TGT后整个域就在攻击者面前敞开了大门。# 方式一使用哈希进行DCSync导出所有域用户哈希 secretsdump.py -hashes :[NTLM_Hash] domain.local/administrator192.168.1.10 # 方式二使用Certipy获取的TGTKirbi文件进行后续操作 # 首先将PFX认证得到的TGT保存下来Certipy auth 命令默认会保存 # 然后使用其他工具如Impacket的psexec利用此TGT export KRB5CCNAME/path/to/administrator.ccache psexec.py -k -no-pass domain.local/administratordc01.domain.local第一种方式是最直接、最致命的。通过DCSync攻击模仿域控制器之间的数据同步可以导出整个AD域中所有用户的密码哈希包括krbtgt账户。这意味着攻击者可以创建“黄金票证”获得域内永久的、不可检测的后门权限。4. 防御策略与深度检测方案理解了攻击链防御就有了清晰的思路。防御的核心原则是打破ESC1依赖的四个条件中的至少一个。4.1 根本性修复收紧证书模板配置这是最有效、最根本的防御措施。审查并移除过宽的注册权限对所有证书模板的ACL进行审计。确保非必要模板的“注册”权限仅授予特定的、确需使用该证书的用户或组绝对不要授予Authenticated Users或Domain Users。对于用于服务器身份验证的模板考虑仅授予对应的服务器计算机账户。禁用“在请求中提供SAN”选项对于所有不需要请求者自定义身份的证书模板坚决取消“主题名称”标签页下的“在请求中提供”选项。如果业务确实需要请求者提供特定信息如DNS名称应启用“在Active Directory中构建”或“在证书申请中提供”并配合严格的审批流程。启用管理者批准对于高权限或高敏感性的证书模板尤其是任何包含客户端认证EKU的模板强制启用“颁发要求”标签页下的“CA证书管理员批准”选项。这为证书颁发增加了一道人工审计关卡。遵循最小权限原则创建模板不要随意修改默认模板。创建新的专用模板时严格遵循其用途。将“客户端认证”、“服务器认证”等不同用途的EKU分离到不同的模板中并分别配置严格的权限。4.2 持续性监控与检测修复配置后需要建立持续的监控机制以发现潜在的异常申请和攻击尝试。监控CA安全事件日志在CA服务器上启用并集中收集Windows安全事件日志中的AD CS相关事件。关键事件ID包括4886证书服务收到请求、4887证书服务颁发证书。分析这些日志关注请求的证书模板、申请者身份Requester与证书主题/SAN中的身份Subject是否不一致。一个普通用户申请了一个SAN为域管理员的证书就是最明显的异常。4896证书服务属性已更改。监控证书模板配置的变更防止配置被恶意修改。SIEM规则构建将上述日志接入SIEM系统并编写关联规则。例如“同一用户短时间内多次申请不同身份的客户端认证证书。”“申请者来自非常用工作站或非管理账户但申请的证书模板具有高权限特征。”“证书申请成功颁发但紧接着该申请者身份或证书中SAN身份出现了异常的登录行为如从非常用IP登录域控。”网络流量分析监控域控制器KDC的88/tcp和88/udp端口流量。使用网络检测工具识别异常的PKINIT认证请求。虽然加密流量内容不可见但可以分析请求频率、源IP等元数据。4.3 高级防护与架构思考对于安全性要求极高的环境可以考虑更激进的措施。实施证书映射限制在AD中可以配置限制使得某些证书只能映射到特定的用户账户。但这需要精细化的管理可能不适用于大规模环境。定期审计与红队演练将AD CS配置审计纳入常规安全审计范围。定期聘请红队或使用自动化工具如Certipy本身、BloodHound进行攻击模拟主动发现类似ESC1的配置弱点。架构隔离考虑将CA服务器置于独立的、权限严格限制的管理林中与生产用户林分离。这可以极大增加攻击者横向移动到CA的难度。5. 实战排查清单与常见问题在实际操作中无论是攻击模拟还是防御排查都会遇到一些典型问题。这里我整理了一份清单和解决方案。5.1 攻击端常见问题与调试问题现象可能原因排查步骤与解决方案certipy find找不到CA或模板网络不通、权限不足、DNS解析问题1. 使用-dc-ip显式指定域控制器IP。2. 确认当前用户是域用户且能访问域控制器。3. 尝试使用-debug参数运行查看详细的LDAP查询和错误信息。certipy req返回权限错误用户对目标模板没有“注册”权限1. 使用certipy find仔细检查模板的PERMISSIONS确认你的用户或所在组有Enroll权限。2. 尝试用-hashes参数传递其他已获取用户的哈希进行认证。certipy req成功但证书无效模板可能启用了“管理者批准”1. 检查模板的FLAGS确认不包含CT_FLAG_PEND_ALL_REQUESTS。2. 在CA管理控制台中查看“挂起的请求”队列你的申请可能在那里等待批准。certipy auth失败提示KDC错误证书EKU不匹配、时间不同步、KDC不支持PKINIT1. 用openssl x509 -in cert.crt -text -noout查看证书详情确认有Client AuthenticationEKU。2. 确保攻击主机与域控制器时间同步误差在5分钟内。3. 极少数老旧环境可能不支持PKINIT可尝试其他攻击方式。获取哈希成功但无法DCSync目标用户权限不足、防火墙阻挡1. 确认你获取的是Administrator或类似高权限账户的哈希。2. DCSync需要与域控制器通信TCP 445, 135, 高阶端口确保网络可达。5.2 防御端排查清单作为防御方你可以按照以下步骤快速评估环境风险清单式检查使用PowerShell脚本或Certipy以只读权限自动化枚举所有CA和模板并输出配置报告重点标记出同时满足ESC1四个条件的模板。日志溯源如果怀疑已发生攻击立即检查CA服务器和域控制器在可疑时间段的4886/4887事件。筛选Subject与Requester不匹配的证书颁发记录。用户行为分析对于在证书日志中发现的异常申请者在其对应的终端上检查命令行历史、进程创建日志寻找Certipy或其他证书操作工具的痕迹。证书吊销如果确认恶意证书已颁发应立即在CA控制台中吊销该证书并将其发布到CRL证书吊销列表。但请注意攻击者可能在吊销前已经使用了证书因此吊销后仍需进行全面的入侵排查。实操心得在真实环境中ESC1的利用成功率非常高因为它太“安静”了。很多管理员甚至不知道自己的环境里存在这样的模板。我个人的习惯是在拿到一个域权限后第一时间不是去抓密码而是运行certipy find。它往往能给我指出一条比漏洞利用更稳定、更隐蔽的提权路径。对于蓝队而言把AD CS的配置安全提到和域控补丁、用户权限管理同等重要的位置是应对现代内网攻击的必修课。