ADCS-ESC3漏洞解析：从证书模板滥用实现域权限提升

1. 项目概述：从“惊天漏洞”到实战演练

最近在内部攻防演练和渗透测试的圈子里，ADCS-ESC3这个名词被反复提及，热度居高不下。很多刚入门安全测试的朋友，一看到“证书提权”、“域管理员”这些字眼，就觉得高深莫测，下意识地认为这是只有资深红队才能玩转的技术。但实际情况是，这个被称为“ESC3”的攻击路径，其原理和利用门槛，可能比你想象的要低得多。它之所以能引起轩然大波，核心在于它巧妙地利用了Active Directory证书服务（ADCS）中一个看似合理的默认配置，将低权限的域用户身份，通过申请一张特定类型的证书，直接转化为域内的高权限身份，甚至一步到位拿到域管理员权限。

这听起来是不是有点像拿到了域内的“万能钥匙”？事实上，它的影响范围确实非常广。只要一个域环境部署了ADCS（很多中大型企业为了内部PKI体系都会部署），并且管理员没有对证书模板的权限进行极其严格的裁剪和审查，那么任何一个普通的域用户，都可能成为潜在的“域管理员”。这不是危言耸听，而是基于ADCS默认配置和Kerberos协议认证机制的一次“合规”滥用。攻击者不需要利用0day漏洞，不需要复杂的漏洞利用链，只需要了解ADCS的基本运作方式和几个PowerShell命令，就能完成一次优雅的权限提升。

所以，这篇文章的目的，就是为你彻底拆解ADCS-ESC3。我不会只停留在“这个漏洞很厉害”的层面，而是会带你从零开始，理解ADCS是什么、证书模板的关键配置在哪里、ESC3攻击的具体原理是什么、以及如何一步步在实验环境中复现和防御。无论你是刚开始接触内网安全的新手，还是想系统化梳理ADCS攻击面的从业者，这篇长文都会提供从原理到实操的完整视角。我们不仅要学会“攻击”，更要理解背后的“为什么”，这样才能真正做好防御。

2. ADCS与证书模板：权限提升的“设计图”

要理解ESC3，必须先搞懂两个核心概念：ADCS（Active Directory证书服务）和证书模板。你可以把ADCS想象成域内的一个“官方印章局”。这个印章局（CA服务器）负责颁发各种用途的“官方文件”（数字证书），比如用来加密邮件的证书、用来登录VPN的证书、或者用来证明计算机身份的证书。而“证书模板”，就是这个印章局里预先设计好的、不同“官方文件”的 标准格式和签发规则 。

关键点来了：这个“标准格式”（证书模板）里，不仅规定了证书的类型（比如是用户证书还是计算机证书），更 隐藏着决定性的权限信息 ——主体备用名称（Subject Alternative Name, SAN）。在ADCS的语境下，SAN字段可以被配置为从请求者的AD属性中动态拉取，例如用户主体名称（UPN）。更重要的是，当这张证书被用于Kerberos认证时，Kerberos协议会 认SAN字段里的身份，而不是证书申请者原本的身份 。

ESC3攻击利用的正是这一点。攻击者会寻找那些满足以下条件的证书模板：

1. 允许域用户注册 ：即低权限用户有权申请该模板的证书。
2. 定义了ENROLLEE_SUPPLIES_SUBJECT ：这意味着申请者可以自己指定证书的主题（Subject）和SAN。
3. 模板定义了基于证书的认证 ：例如，模板用途包含了“客户端认证”或“智能卡登录”。
4. 该模板被配置了任何扩展的密钥用法（EKU） ：但最关键的是，管理该模板的访问控制列表（ACL）中，包含了 允许低权限用户写入 msPKI-Certificate-Name-Flag 属性 的权限。这个属性控制着SAN的来源。如果低权限用户可以修改它，他们就能将SAN设置为任何域用户（比如域管理员）。

简单来说，攻击者找到一个“设计图”（漏洞证书模板），这个设计图允许普通员工（低权限域用户）来自定义“官方文件”（证书）上写谁的名字。然后，攻击者就在申请时，把名字写成“公司CEO”（域管理员）。接着，“印章局”（CA）基于这个有问题的设计图，真的颁发了一张写着CEO名字的“官方文件”。最后，攻击者拿着这张“CEO文件”去访问公司核心系统（Kerberos认证），系统一看文件上的名字是CEO，就授予了CEO的权限。

注意 ：这里描述的是一种典型的ESC3场景（CVE-2022-26923的变体或类似错误配置）。在实际中，漏洞可能源于模板ACL配置不当，允许用户修改关键属性，从而控制SAN。而ADCS的默认模板中，某些配置可能过于宽松，为这种攻击创造了条件。

3. ESC3攻击链深度拆解：一步一脚印的提权之路

理解了核心原理，我们来看看一次完整的ESC3攻击链具体是如何串联起来的。这个过程就像一场精心策划的“身份窃取”，每一步都利用了ADCS和Windows认证体系的特性。

3.1 第一步：信息收集与侦察

在发动攻击之前，我们必须先摸清目标域的环境。这不需要任何特殊权限，一个普通的域用户足矣。

1. 发现CA服务器 ：通常可以通过LDAP查询或扫描网络中的特定端口（如TCP 636 LDAPS, 443等）来定位域内的证书颁发机构（CA）。使用 certutil 命令或PowerShell的 Get-CertificationAuthority 命令可以很方便地枚举出来。
2. 枚举证书模板 ：这是最关键的一步。我们需要列出CA上所有可用的证书模板，并分析它们的属性。强大的工具如 Certify.exe （SharpCollection项目的一部分）或 PSPKIAudit 模块可以自动化完成这项工作。它们会检查每个模板的权限、是否允许域用户注册、是否允许申请者指定主题、以及关键的ACL设置。
3. 识别漏洞模板 ：工具会高亮显示那些配置存在问题的模板。我们要寻找的就是同时具备“域用户可注册”、“允许申请者提供主题”、“SAN可被申请者控制”这几个特征的模板。通常，一些用于“用户”或“智能卡用户”的模板，如果管理员未做严格限制，就可能中招。

实操心得 ：在实际环境中，信息收集阶段一定要安静。避免使用会触发大量日志的扫描方式。 Certify 的 /quiet 参数很有用。此外，不要只依赖一种工具，用 Certify 和PowerShell命令交叉验证结果，能提高准确性。

3.2 第二步：滥用模板，伪造身份

一旦找到目标模板，攻击就进入了实质阶段。我们假设找到了一个名为“VulnerableUserTemplate”的模板。

1. 构造恶意证书请求 ：攻击者会使用工具（如 Certify 的 request 子命令）向CA申请该模板的证书。在请求中，关键操作是指定 /altname 参数。这个参数就是用来设置SAN字段的。攻击者会在这里填入目标提升权限的账户名，例如域管理员 administrator@corp.local 。
2. 触发CA签发 ：CA服务器收到请求后，会根据“VulnerableUserTemplate”模板的规则进行处理。由于模板配置允许申请者指定SAN，并且ACL错误地允许低权限用户执行此操作，CA 不会进行额外的身份验证 ，就会基于攻击者提供的SAN信息签发证书。于是，一张主体备用名称（SAN）为 administrator@corp.local 的证书，就颁发给了最初的低权限用户。

这里面的深层逻辑 ：CA的信任是基于模板配置的。它认为“允许注册此模板的用户”+“模板允许的配置”这个组合是合法的。它没有第二道机制去校验“用户申请的SAN是否与他自身的身份匹配”。这正是整个攻击链得以成立的设计缺陷或配置疏忽。

3.3 第三步：证书到TGT，完成权限转换

拿到这张“冒名”证书后，攻击者还不能直接用。需要将它转换为Kerberos协议认可的“门票”。

1. 将证书转换为票据授予票据（TGT） ：在Windows域环境中，Kerberos认证是核心。我们可以使用 Rubeus.exe 这个工具来完成这一步。执行命令如 Rubeus.exe asktgt /user:administrator /certificate:申请的证书.pfx /password:证书密码 /ptt 。这个命令的核心作用是：向域控制器（KDC）出示这张“管理员”证书，申请一张属于“管理员”这个身份的TGT票据。
2. KDC的认证过程 ：域控制器收到请求后，会验证证书的有效性（是否由受信任的CA签发、是否在有效期内等）。验证通过后，KDC 看到证书中的SAN是administrator ，于是它就认为这是administrator在申请票据。因此，它签发的TGT票据，其包含的权限就是域管理员 administrator 的权限。
3. 票据注入内存（PTT） ： /ptt 参数的意思是“Pass The Ticket”，即将申请到的TGT票据自动注入到当前Windows会话的内存中。至此，攻击者当前的操作系统会话，在后续的网络认证中，就会使用这张高权限的TGT来证明自己是“域管理员”。

3.4 第四步：权限验证与利用

票据注入后，攻击需要验证是否真的提权成功，并开始利用。

1. 验证权限 ：最直接的方式是使用 klist 命令查看当前会话的票据，确认是否有 administrator@CORP.LOCAL 的TGT。然后，可以尝试访问域管理员才有权限访问的资源，例如使用 dir \\域控制器\c$ 来列出域控制器C盘目录。如果成功，则证明提权完全生效。
2. 横向移动与持久化 ：获得域管理员权限后，整个域就门户大开了。攻击者可以：
   • DCSync ：使用 mimikatz 或 secretsdump.py 进行DCSync攻击，导出域内所有用户的哈希值，获取黄金/白银票据的原料。
   • GPO滥用 ：通过组策略对象在域内所有计算机上部署后门或执行命令。
   • 创建后门账户 ：直接在域控上创建新的域管理员账户。
   • 黄金票据 ：利用获取到的krbtgt账户哈希，制作黄金票据，实现不受限制的域内持久化访问。

注意事项 ：从证书申请到票据注入，整个过程可能会在Windows安全日志（特别是Windows Security日志中的4768、4769事件）和ADCS的CA日志中留下记录。在真实的渗透测试中，需要结合免杀、日志清理（需授权）等手段进行规避。对于防御方而言，这些日志是检测ESC3攻击的关键溯源点。

4. 从零搭建实验环境与复现实操

理论讲得再多，不如亲手做一遍。下面我将详细演示如何在实验室环境中搭建靶场并复现ESC3攻击。请确保所有操作都在你自己控制的、隔离的虚拟化环境中进行。

4.1 实验环境准备

你需要一个简单的域环境，至少包含：

• 一台域控制器（DC） ：安装Windows Server 2016/2019/2022，并提升为域控制器（比如 corp.local ）。
• 一台成员服务器（CA服务器） ：加入域，并安装“Active Directory证书服务”角色。在安装过程中，选择同时安装“证书颁发机构”和“证书颁发机构Web注册”。确保CA是企业根CA。
• 一台客户端机器（攻击机） ：可以是加入域的Windows 10/11，也可以是不加域但能连通域网络的机器（需配置DNS）。上面需要安装必要的攻击工具。
• 一个低权限域用户 ：在DC上创建一个普通域用户，例如 lowuser ，并将其添加到CA服务器的“Domain Users”组中即可。

安装ADCS的关键步骤 ： 在CA服务器上，通过服务器管理器添加角色，选择“Active Directory证书服务”。在角色服务中，务必勾选“证书颁发机构”和“证书颁发机构Web注册”。在设置CA类型时，选择“企业CA”；在指定CA类型时，选择“根CA”；在私钥配置页面，新建私钥；在后续的配置中，使用默认设置即可。安装完成后，需要 在CA服务器上以管理员身份运行 certsrv.msc ，来管理证书模板。

4.2 配置“漏洞”证书模板

默认情况下，可能没有现成的模板完全符合ESC3条件，我们需要复制一个模板并修改其配置。

1. 打开证书模板控制台 ：在CA服务器上，运行 certsrv.msc ，右键“证书模板”->“管理”。
2. 复制模板 ：找到一个基础模板，例如“用户”模板。右键点击它，选择“复制模板”。
3. 配置关键设置 ：
   • 兼容性 ：将CA和申请者都设置为“Windows Server 2016”或更高，以获得更灵活的设置选项。
   • 常规 ：给新模板起个名字，如 ESC3_Vuln_Template 。
   • 使用者名称 ：这是 核心中的核心 ！选择“在请求中提供”。这将启用“ENROLLEE_SUPPLIES_SUBJECT”标志。
   • 扩展 ：在“应用程序策略”中，确保包含“客户端身份验证”。在“颁发要求”中，管理员批准可以取消。
   • 安全 ：确保“域用户”组拥有“注册”的权限。 为了模拟最典型的错误配置，我们还需要赋予“域用户”对模板对象本身更高级的权限 。这需要通过ADSI编辑器（ adsiedit.msc ）来完成，导航到 CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local ，找到你的模板，编辑其安全设置，给“Domain Users”添加“写入”权限，特别是对 msPKI-Certificate-Name-Flag 属性的写入权。 这正是很多现实环境中由于管理疏忽或脚本配置错误导致的问题 。
4. 发布模板 ：配置好后，在证书颁发机构控制台中，右键“证书模板”->“新建”->“要颁发的证书模板”，选择刚才创建的 ESC3_Vuln_Template ，将其发布到CA。

4.3 攻击复现详细步骤

假设我们已在客户端机器上，以低权限域用户 lowuser 登录。

1. 工具准备 ：下载 Certify.exe 和 Rubeus.exe 到攻击机。
2. 信息收集 ：

   # 使用Certify枚举CA和模板
   Certify.exe find /vulnerable
   

   观察输出，找到我们刚创建的 ESC3_Vuln_Template ，确认其 ENROLLEE_SUPPLIES_SUBJECT 为 True ，且 LowPriv （低权限用户可注册）为 True 。
3. 申请恶意证书 ：

   # 指定漏洞模板和管理员身份
   Certify.exe request /ca:CA-SERVER.corp.local\CORP-CA /template:ESC3_Vuln_Template /altname:administrator
   

   执行后， Certify 会与CA交互，完成证书申请、生成私钥，并最终将证书（.pfx格式，包含私钥）以Base64格式输出在屏幕上。你需要将 -----BEGIN PKCS7----- 到 -----END PKCS7----- 之间的内容（或工具直接输出的.pfx文件）保存下来，例如为 admin.pfx 。注意，申请过程中可能需要通过 /credential 参数指定 lowuser 的密码。
4. 转换证书为TGT票据 ：

   # 使用Rubeus，将证书文件转换为TGT并注入内存
   Rubeus.exe asktgt /user:administrator /certificate:C:\Tools\admin.pfx /password:证书密码 /ptt
   

   如果证书是Base64字符串，可以使用 /certificate:BASE64... 格式。执行成功后，会看到“Ticket successfully imported!”的提示。
5. 验证权限 ：

   # 查看当前票据
   klist
   # 尝试访问域控制器的C盘
   dir \\dc.corp.local\c$
   

   如果 dir 命令成功执行，列出了域控制器C盘根目录，那么恭喜你，ESC3攻击复现成功！ lowuser 已经成功窃取了 administrator 的身份。

实操现场记录与参数解析 ：

• /ca 参数：格式为 CA主机名\CA名称 。CA名称可以在CA服务器的 certsrv.msc 控制台首页看到。
• /altname ：这是攻击的灵魂参数。它直接写入证书的SAN扩展项。除了UPN，理论上也可以尝试其他名称格式，但UPN是最直接有效的。
• /ptt ：这是实现“无痕”攻击的关键。票据只存在于内存中，重启即消失，避免了在磁盘上留下二进制文件证据。当然，你也可以用 /opsec 参数来生成一个 .kirbi 文件，用于后续的传递或离线使用。

5. 防御策略与深度加固指南

攻击很犀利，但防御也并非无计可施。防御ESC3的核心思路是： 收紧证书模板的权限，遵循最小权限原则，并建立有效的监控 。

5.1 证书模板权限审计与收紧

这是最根本的防御措施。

1. 禁用或删除不必要模板 ：定期审查CA上发布的证书模板，将那些不再使用或非必需的模板 取消发布 （在CA控制台中右键模板->“删除”），或直接删除。
2. 严格审查模板安全描述符 ：
   • 对于必须存在的用户证书模板，移除“Domain Users”组的“注册”权限，改为更细化的安全组（如“需要证书的用户组”）。
   • 重中之重 ：使用 adsiedit.msc 或PowerShell的 Get-Acl / Set-Acl ，检查每个证书模板对象的ACL。 确保没有任何低权限用户或组拥有“写入”或“完全控制”权限 ，特别是对 msPKI-Certificate-Name-Flag 、 msPKI-Enrollment-Flag 、 msPKI-Certificate-Application-Policy 等关键属性的写入权。默认的“读取”和“注册”权限是安全的。
3. 限制“使用者名称”设置 ：对于大多数用户模板， 绝对不要使用“在请求中提供” 。应该选择“在Active Directory中生成”或“使用来自Active Directory的信息”。这从根本上杜绝了申请者自定义身份的可能。
4. 启用管理员批准 ：对于高权限或敏感的证书模板，勾选“颁发要求”中的“CA证书管理员批准”。这样每次证书申请都需要管理员手动审批，增加了安全闸门。

5.2 CA服务器与ADCS服务加固

1. 网络隔离 ：将CA服务器放置在专用的管理网络段，严格限制访问源。只允许必要的管理终端和域控制器与之通信。
2. 启用CA审核 ：在CA服务器上，启用“审核对象访问”策略，并在CA管理控制台中配置审核，记录所有证书的申请、颁发、拒绝事件。定期分析这些日志。
3. 使用基于角色的访问控制（RBAC） ：如果企业规模较大，考虑部署ADCS的RBAC功能，将证书注册、管理、审核等职责分离。

5.3 主动监控与检测

防御不能只靠静态配置，还需要动态的眼睛。

1. 监控可疑的证书申请事件 ：在CA服务器的Windows安全日志中，关注事件ID为 4886 和 4887 的事件（证书服务请求）。特别留意那些：
   • 申请模板是高风险模板（如自定义的、权限宽松的模板）。
   • 申请者身份是普通用户，但证书中的使用者名称（Subject）或SAN是管理员账户。
   • 短时间内来自同一用户的大量证书申请。
2. 监控Kerberos认证日志 ：在域控制器上，监控事件ID 4768 （TGT请求）和 4769 （服务票据请求）。如果发现一个用户账户（如 lowuser ）突然使用证书（认证类型为 PKINIT ）申请了高权限账户（如 administrator ）的TGT，这就是极其强烈的ESC3攻击告警信号。
3. 使用SIEM或EDR聚合分析 ：将CA日志、域控制器Kerberos日志、甚至终端上的进程创建日志（谁执行了Certify/Rubeus）进行关联分析。可以构建这样的检测规则：“同一源主机，先出现对漏洞模板的证书申请（事件4886），紧接着出现以管理员身份通过PKINIT的TGT请求（事件4768）”。

5.4 应急响应与缓解措施

如果怀疑已经遭受ESC3攻击，应立即采取以下措施：

1. 立即隔离CA服务器 ：从网络层面断开CA服务器，防止攻击者继续申请恶意证书。
2. 吊销可疑证书 ：在CA控制台中，根据申请时间、申请者等信息，找到并吊销所有可疑的证书。务必发布最新的证书吊销列表（CRL）。
3. 重置受影响账户凭据 ：如果攻击者可能已获取域管理员哈希（通过DCSync），必须立即重置域内所有高权限账户（尤其是krbtgt账户）的密码。注意，krbtgt账户需要重置两次。
4. 全面审计与加固 ：按照上述防御指南，对域内所有CA和证书模板进行一次彻底的安全审计和加固。

6. 常见问题与排查技巧实录

在实际操作和防御中，你肯定会遇到各种各样的问题。下面我整理了一些典型场景和解决思路。

6.1 攻击复现阶段常见问题

问题1：使用 Certify.exe 枚举时，找不到任何 /vulnerable 的模板。

• 排查思路 ：
  • 确认当前用户确实是域用户，并且能解析域内DNS，能访问CA服务器。
  • 使用 Certify.exe find 不带参数，先看看能否列出所有模板。如果连模板都列不出，可能是网络或权限问题。
  • 检查CA服务器名称是否正确。 /ca 参数有时需要完整的DNS名称。
  • 可能是工具版本问题。尝试更新 Certify 到最新版。
  • 最可能的原因 ：实验环境中没有配置出真正的“漏洞模板”。回顾4.2节，确保你不仅复制了模板、设置了“在请求中提供”，还通过ADSI编辑器赋予了Domain Users对该模板对象的“写入”权限。这是模拟常见错误配置的关键一步。

问题2：申请证书时失败，提示“访问被拒绝”或“找不到模板”。

• 排查思路 ：
  • 模板名错误 ：用 Certify.exe find 确认模板的准确名称，注意大小写。
  • CA名称错误 ：格式为 主机名\CA名 。CA名可以在CA服务器的 certsrv.msc 首页看到，不是服务器的主机名。
  • 权限不足 ：即使模板允许注册，如果当前用户不在允许注册的组里，也会失败。检查模板的“安全”选项卡。
  • 证书服务未运行 ：检查CA服务器上的“Active Directory Certificate Services”服务是否正在运行。

问题3： Rubeus.exe asktgt 失败，提示“KDC_ERR_PADATA_TYPE_NOSUPP”或“KDC无法找到证书”。

• 排查思路 ：
  • 证书问题 ：确保证书文件（.pfx）路径正确，密码正确。可以用 Rubeus.exe asktgt /user:test /certificate:... /password:... （不加 /ptt ）先测试证书本身是否能被解析。
  • 时间不同步 ：域成员机器和域控制器的时间差不能超过5分钟。检查时间同步。
  • 证书链问题 ：攻击机需要信任颁发证书的CA。在实验环境中，你需要将CA的根证书导入到攻击机的“受信任的根证书颁发机构”存储中。可以从 http://<ca-server>/certsrv 下载CA证书链。
  • 用户主体名称（UPN）问题 ：确保 /altname 参数指定的管理员UPN完全正确，包括域名部分。

6.2 防御与排查阶段常见问题

问题4：如何快速批量检查域内所有证书模板的安全性？

• 解决方案 ：手动检查效率太低。可以使用PowerShell脚本或现成工具进行自动化审计。
  • PSPKIAudit模块 ：这是一个非常强大的PowerShell模块。以管理员身份运行PowerShell，安装后执行 Invoke-PKIAudit -DomainController <DC> -OutputPath .\audit.html ，可以生成一份详细的HTML报告，清晰标出存在配置问题的模板。
  • Certify的审计功能 ： Certify.exe find 的输出本身就包含了关键的安全属性，可以编写脚本解析其输出，筛选出 ENROLLEE_SUPPLIES_SUBJECT 为 True 且低权限可注册的模板。

问题5：监控日志量太大，如何精准定位可疑事件？

• 解决方案 ：在SIEM或日志分析平台中建立精准的过滤规则。
  • CA日志（事件4886） ：过滤条件是 Template Name 包含你定义的高风险模板名称（如 ESC3_Vuln_Template 、 User 等），并且 Requester 不是特定的服务账户或管理员账户。
  • DC日志（事件4768） ：过滤条件是 Authentication Type 为 PKINIT ，并且 Account Name （请求票据的账户）与 Service Name （票据所属的账户）不一致。例如， Account Name 是 lowuser ，而 Service Name 是 administrator 。这几乎可以确认为证书滥用攻击。

问题6：已经加固了模板，但担心之前颁发的证书被滥用怎么办？

• 解决方案 ： 立即吊销并发布CRL 。
  1. 在CA控制台的“颁发的证书”中，根据时间、申请者等信息找到可疑证书，右键“所有任务”->“吊销证书”，选择吊销理由（如“密钥泄露”）。
  2. 右键CA名称，选择“所有任务”->“发布”，发布新的CRL。
  3. 确保域内所有依赖证书的应用和服务（如VPN、Wi-Fi）都配置了检查CRL。这样，攻击者即使持有旧证书，也会在下次认证时因证书被吊销而失败。

6.3 高级技巧与思考

技巧1：在受限环境下获取工具。 在高度受限的测试环境，可能无法直接上传exe。可以考虑：

• 内存加载 ：使用 Cobalt Strike 、 Meterpreter 的 execute-assembly 功能，或 PowerShell 的 ReflectiveAssembly 技术，将 Certify 、 Rubeus 的.NET程序集直接加载到内存中执行，不落地。
• 纯PowerShell实现 ：研究并编写纯PowerShell脚本来实现证书请求和PKINIT过程，虽然复杂，但规避了可执行文件检测。

技巧2：理解变种与绕过。 ESC3是ADCS攻击面的一种。还有ESC1（模板允许任意SAN且管理器批准）、ESC2（模板允许任意SAN但用于不同用途）等。防御时不能只盯着一点，需要对所有证书模板的以下属性进行整体审查： mspki-enrollment-flag (包含 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT ), mspki-certificate-name-flag (包含 CT_FLAG_SUBJECT_ALT_REQUIRE_UPN 等), 以及模板的ACL。使用 PSPKIAudit 这类工具可以一次性完成全面评估。

技巧3：红队视角下的隐蔽行动。 在真实的对抗中，直接申请管理员证书动静太大。可以尝试：

• 先申请一个中间权限的证书（如IT支持人员），用该身份进行横向移动，再寻找机会接触CA或更高权限模板。
• 利用“基于资源的约束委派”（RBCD）与证书攻击结合。如果一台计算机账户有权在CA上注册证书，那么攻击该计算机账户也可能成为一条路径。
• 时刻关注日志清理（需在授权范围内），了解防守方的监控规则，尝试在非工作时间或通过合法的管理通道（如已授权的跳板机）进行操作，增加检测难度。