作者 akihi（白帽攻防录讲师），某甲方网络安全工程师，合合 SRC 年度第一、腾讯 SRC 连续三年前十，单漏洞赏金 4w+，擅长 Web/App/PC 客户端漏洞挖掘。专注企业域安全、AD CS 证书滥用、Kerberos 认证攻击。本文基于公开 CVE 信息与技术原理深度复盘，供安全研究与防护参考。
一、漏洞时间线
2026 年 7 月，微软补丁星期二修复了一个 Active Directory Certificate Services（AD CS）的严重漏洞 CVE-2026-54121，代号 Certighost。这个漏洞让一个普通的域用户------不需要管理员权限------就能让企业 CA 颁发一张"域控制器身份"的证书。拿到这张证书，攻击者就能伪造域控制器身份，执行 DCSync 窃取整个域的所有密码哈希，包括域管和 krbtgt 账户------等于完全控制整个企业域。
| 时间 | 事件 | 影响版本 |
|---|---|---|
| 2026-07-14 | 微软 7 月补丁星期二修复 | AD CS Enterprise CA |
| 2026-07-24 | 安全社区公开技术分析 | ------ |
| 2026-07-27 | 研究者发布公开 PoC | ------ |
| 2026-08-04 | Nextron 发布检测规则 | ------ |
| 2026-09-28 | 安全社区汇总 AD CS 漏洞 | ------ |
这个漏洞最可怕的地方在于：它是一个"信任边界失效"------CA 在颁发证书时，本来应该验证"你说你是 DC，那你真的是 DC 吗？"。但 Certighost 漏洞里，CA 会跟着证书请求里的 cdc 属性去连接攻击者指定的服务器，而不验证这个服务器是不是真的域控制器。结果就是：攻击者自己搭一个假服务器，骗 CA 说"我就是那个 DC"，CA 就真的颁发了 DC 身份的证书。
二、攻击链全景
让我们先用一张流程图还原完整的攻击路径：
攻击者在企业内网有一个普通域用户账号
│
▼
第一步：准备伪造环境
│ 攻击者需要：
│ - 一个普通域用户账号
│ - 一台能控制的机器
│ - 能搭伪造的 Netlogon/LDAP 服务
│ - 知道目标 DC 的名字和 SID
│
│ 关键配置：
│ CA 开了 EDITF_ENABLECHASECLIENTDC
│ 这个标志位让 CA 跟随
│ 证书请求里的 cdc 属性
▼
第二步：提交恶意证书请求
│ 攻击者用普通域用户
│ 向 Enterprise CA 提交证书请求
│
│ 证书请求里包含：
│ - cdc 属性：指向攻击者的伪造服务器
│ - rmd 属性：指向目标 DC 的机器对象
│
│ 意思是：
│ "CA 大人，你要验证我的身份
│ 就去问这个服务器（我的服务器）"
▼
第三步：CA chase 机制触发
│ CA 收到请求后：
│ 因为配置了 chase 机制
│ 它会跟着 cdc 属性
│ 去连接攻击者指定的服务器
│
│ CA 在连接时：
│ 用 SMB/LDAP 协议
│ 向伪造服务器验证身份
│
│ 但伪造服务器是攻击者控制的！
│ 它返回：
│ - 目标 DC 的 objectSid
│ - 目标 DC 的 dNSHostName
│
│ CA 信了！
▼
第四步：CA 颁发 DC 身份证书
│ CA 认为验证通过了
│ 就颁发了一张证书
│ 证书里包含：
│ - 目标 DC 的 SID
│ - 目标 DC 的 DNS 名称
│
│ 这张证书是 CA 签名的！
│ 在整个域里都受信任！
▼
第五步：PKINIT 获得 DC 身份 TGT
│ 攻击者用这张证书
│ 通过 PKINIT 协议
│ 向 KDC 申请 Kerberos TGT
│
│ KDC 看到证书是 CA 签的
│ 里面的身份是 DC
│ 就真的发了一个 DC 的 TGT！
│
│ 攻击者现在
│ 就是域控制器了
▼
第六步：DCSync 窃取所有密码
│ 有了 DC 身份
│ 攻击者就有权限
│ 执行目录复制同步（DCSync）
│
│ 能偷到：
│ - 域管的密码哈希
│ - 所有域用户的密码哈希
│ - krbtgt 账户的密码哈希
│
│ 有了 krbtgt
│ 就能伪造 Golden Ticket
│ 永久控制整个域
▼
攻击者完全控制整个企业域
│
├─ 冒充任何用户身份
├─ 访问所有域内资源
├─ 创建后门管理员账户
└─ 持久化控制整个森林**关键结论：**这个漏洞的本质是"身份验证逻辑错误"------CA 的 chase 机制本来是为了解决"怎么验证请求者身份"的问题，但它信任了请求者自己指定的服务器，而不验证这个服务器是不是真的域控制器。就像你去办身份证，窗口说"你证明一下你是谁"，你说"你去问那个人（你朋友）"，然后你朋友说"他就是某某某"，窗口就信了------这就是信任模型的问题。
三、AD CS 与证书认证原理
3.1 什么是 AD CS
Active Directory Certificate Services 是微软的公钥基础设施：
| 组件 | 功能 |
|---|---|
| AD CS | Active Directory 证书服务，企业 CA |
| Enterprise CA | 企业级证书颁发机构 |
| 证书申请 | 用户/设备向 CA 申请证书 |
| chase 机制 | CA 验证请求者身份的回退机制 |
| PKINIT | 用证书进行 Kerberos 认证 |
3.2 什么是 chase 机制
chase 是 CA 验证身份的回退机制：
// chase 机制是什么？
// 正常流程：
// - 用户申请证书
// - CA 验证用户身份
// - 颁发证书
// 但有些时候：
// - CA 没法直接确定请求者是谁
// - 比如机器账户申请证书
// - 或者是跨域的场景
// chase 机制：
// - 证书请求里可以带 cdc 属性
// （要联系的 AD 服务器）
// - 还可以带 rmd 属性
// （要解析的机器对象）
//
// CA 就会：
// 1. 连接 cdc 指定的服务器
// 2. 查询 rmd 指定的对象
// 3. 拿到对象的身份信息
// 4. 基于这个信息颁发证书
// 问题在哪里？
// - cdc 属性是请求者指定的！
// - CA 不验证这个服务器是不是真的 DC
// - 就直接连接了
// - 然后信任返回的信息
//
// 这就是 Certighost 的根因3.3 什么是 PKINIT 和 DCSync
这两个是攻击链的关键环节：
// PKINIT 是什么？
// Kerberos 认证 normally：
// - 用户输密码
// - KDC 验证密码哈希
// - 发 TGT
// PKINIT 是：
// - 用户用证书认证
// - KDC 验证证书签名
// - 如果证书是受信任的 CA 签的
// - 就发对应身份的 TGT
//
// 所以：
// - 有了 DC 身份的证书
// - PKINIT 就能拿到 DC 的 TGT
// DCSync 是什么？
// 正常情况下：
// - 域控制器之间
// - 会同步目录数据
// - 比如密码修改了
// - 要同步到其他 DC
// DCSync 攻击：
// - 如果你有 DC 的权限
// - 你就能发起目录复制
// - 从其他 DC 拉取所有用户的密码哈希
//
// 这就是为什么
// 有了 DC 身份
// 就能偷整个域的密码四、漏洞深度分析
4.1 漏洞根因：cdc 属性未验证
根据安全研究者的分析，漏洞的根本原因是 CA 不验证 chase 目标：
// 有缺陷的逻辑（伪代码）
// 证书申请处理流程：
// 1. 收到证书请求
// 2. 检查请求里有没有 cdc 属性
// 3. 如果有 cdc 属性：
// - 连接 cdc 指定的服务器
// - 查询 rmd 指定的对象
// - 拿到对象的 SID 和 DNS 名
// 4. 颁发包含这个身份的证书
// 问题在哪里？
//
// 步骤 3 应该验证：
// - cdc 指定的服务器
// 是不是真的域控制器？
//
// 但实际代码：
// - 直接连接了
// - 不验证服务器身份
// - 信任返回的所有信息
//
// 修复方式：
// 微软加了
// CRequestInstance::_ValidateChaseTargetIsDC
// 这个函数
// 专门验证 chase 目标是不是真的 DC4.2 触发条件：EDITF_ENABLECHASECLIENTDC
不是所有 CA 都受影响，需要特定配置：
// 漏洞触发条件
// 这个漏洞需要：
// - CA 配置了
// EDITF_ENABLECHASECLIENTDC 标志位
// - 这个标志在 EditFlags 里
// - 是 bit 0x00100000
//
// 这个标志是干什么的？
// - 启用"客户端指定 DC"的 chase
// - 也就是：
// 证书请求里可以带 cdc 属性
// CA 就去连接那个服务器
//
// 为什么很多企业开了？
// - 因为这是可选配置
// - 有些企业为了跨域场景
// - 或者为了兼容性
// - 就开了
//
// 但开了就有风险
// - 普通域用户就能利用4.3 完整攻击链
从普通域用户到完全控制域：
// 完整攻击步骤
// 前置条件：
// - 攻击者有普通域用户账号
// - 企业用了 AD CS Enterprise CA
// - CA 开了 EDITF_ENABLECHASECLIENTDC
// 第一步：环境探测
// - 攻击者用普通账号登录
// - 枚举域内的 CA
// - 检查 CA 配置
// - 确认有这个标志位
// 第二步：搭伪造服务器
// - 攻击者在自己的机器上
// - 搭伪造的 Netlogon/LDAP 服务
// - 准备好返回目标 DC 的信息
// 第三步：提交证书请求
// - 用 Certify 之类的工具
// - 提交带 cdc/rmd 属性的请求
// - cdc 指向自己的伪造服务器
// 第四步：拿到 DC 证书
// - CA 跟着 cdc 来连接
// - 伪造服务器返回真实 DC 的身份
// - CA 就颁发了证书
// 第五步：PKINIT 认证
// - 用 Rubeus 之类的工具
// - 通过 PKINIT 拿到 DC 的 TGT
// 第六步：DCSync
// - 用 mimikatz/impacket
// - 执行 DCSync
// - 偷所有密码哈希
// - 包括 krbtgt
// 第七步：持久化
// - 用 krbtgt 哈希
// - 伪造 Golden Ticket
// - 永久控制整个域4.4 影响范围
| 项目 | 详情 |
|---|---|
| CVE 编号 | CVE-2026-54121 |
| 漏洞类型 | 权限提升 / 认证绕过 |
| 影响产品 | Windows AD CS Enterprise CA |
| 影响配置 | 开启 EDITF_ENABLECHASECLIENTDC 的 CA |
| 发现者 | H0j3n 和 Aniq Fakhrul |
| 利用条件 | 普通域用户账号 |
| 用户交互 | 不需要 |
| CVSS 评分 | 8.8（高） |
| 公开 PoC | 有公开可用的 PoC |
| 影响 | 域控制器冒充，完全控制域 |
五、修复方案分析
微软在 2026 年 7 月补丁星期二中修复了这个问题：
| 修复项 | 修复方式 |
|---|---|
| chase 目标验证 | 增加 _ValidateChaseTargetIsDC 验证 |
| 身份信任边界 | 不再信任请求者指定的服务器 |
| 证书颁发控制 | 严格验证证书请求者身份 |
5.1 AD CS 安全设计原则
// AD CS 安全原则
// 1. 最小权限
// 不要给普通用户太多证书模板权限
// 按需授予
// 2. 严格验证
// 颁发证书前
// 一定要验证请求者身份
// 不能信任请求者自己说的
// 3. 配置审计
// 定期审计 CA 配置
// 检查有没有危险的标志位
// 4. 及时更新
// AD CS 漏洞影响极大
// 要及时打补丁
// 5. 监控异常
// 监控异常的证书请求
// 监控 PKINIT 认证异常5.2 域安全最佳实践
// 域安全检查清单
// 1. 及时打补丁
// 微软每月补丁星期二
// 一定要及时更新
// 2. 审计 AD CS 配置
// 用 Certify/Certipy 之类的工具
// 检查 CA 配置有没有问题
// 3. 最小权限原则
// 普通用户不要给太多权限
// 域管账号要严格管控
// 4. 监控异常行为
// 监控 DCSync 行为
// 监控异常的 Kerberos 认证
// 监控异常的证书请求
// 5. 分段防御
// 域管账号不要在普通机器登录
// 用 PAM 堡垒机管理
// 6. 定期渗透测试
// 定期测试域安全
// 发现并修复配置问题六、SRC 审计启示录
6.1 域安全审计清单
在 SRC 挖洞过程中，针对企业域的审计清单：
| # | 检查项 | 检测方法 |
|---|---|---|
| 1 | AD CS 配置是否安全 | 用 Certify 枚举 CA 和模板 |
| 2 | 有没有危险的证书模板 | 检查 EKURG、ENROLLEE_SUPPLIES_SUBJECT |
| 3 | CA 有没有危险标志位 | 检查 EDITF_ENABLECHASECLIENTDC 等 |
| 4 | 有没有过度权限 | 检查普通用户的权限 |
| 5 | 监控有没有异常 | 检查安全日志有没有告警 |
6.2 常见 AD CS 漏洞类型
// 常见的 AD CS 漏洞
// 1. 证书模板滥用
// 证书模板配置不安全
// 普通用户能申请高权限证书
// 2. ESC1-ESC8 系列
// 各种证书模板错误配置
// 导致的权限提升
// 3. CA 配置错误
// 比如 Certighost 这种
// CA 本身的配置问题
// 4. 证书认证绕过
// 用证书冒充其他用户
// 不需要密码
// 5. PKINIT 相关
// 证书认证流程的问题6.3 暴露面分级
| 暴露级别 | 情况 | 风险 |
|---|---|---|
| 严重 | 普通用户能冒充 DC | 整个域被攻破 |
| 高 | 普通用户能申请管理员证书 | 域管权限被偷 |
| 中 | 特定用户能申请高权限证书 | 有限提权 |
| 低 | 信息泄露 | 辅助攻击 |
七、防护建议
- 及时打补丁：安装 2026 年 7 月或之后的 Windows 更新
- 审计 CA 配置：检查 EDITF_ENABLECHASECLIENTDC 标志位是否必要
- 最小权限：普通用户不要给太多证书申请权限
- 监控异常证书请求：监控异常的证书申请行为
- 定期渗透测试：用 Certify/Certipy 测试 AD CS 配置
- 分段防御：域管账号严格管控，用 PAM 堡垒机
八、总结
Certighost（CVE-2026-54121）是 AD CS 安全的一个经典案例：企业公钥基础设施本来是用来增强安全性的，但配置错误反而成了攻击入口。在企业域安全领域，AD CS 是最高价值的攻击面之一------一个配置错误的 CA，能让普通域用户直接变成域管。理解证书信任模型、PKINIT 认证、DCSync 攻击，是做企业域安全的基本功。在 SRC 挖洞实践中，企业内网的 AD CS 审计是赏金最高的方向之一------一个能拿域管的漏洞，对企业来说价值极高。
