企业官网建设流程全解析

作者 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 账户——等于完全控制整个企业域。

这个漏洞最可怕的地方在于：它是一个"信任边界失效"——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 是微软的公钥基础设施：

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 目标是不是真的 DC

4.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 影响范围

五、修复方案分析

微软在 2026 年 7 月补丁星期二中修复了这个问题：

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 挖洞过程中，针对企业域的审计清单：

6.2 常见 AD CS 漏洞类型

// 常见的 AD CS 漏洞 // 1. 证书模板滥用 // 证书模板配置不安全 // 普通用户能申请高权限证书 // 2. ESC1-ESC8 系列 // 各种证书模板错误配置 // 导致的权限提升 // 3. CA 配置错误 // 比如 Certighost 这种 // CA 本身的配置问题 // 4. 证书认证绕过 // 用证书冒充其他用户 // 不需要密码 // 5. PKINIT 相关 // 证书认证流程的问题

6.3 暴露面分级

七、防护建议

1. 及时打补丁：安装 2026 年 7 月或之后的 Windows 更新
2. 审计 CA 配置：检查 EDITF_ENABLECHASECLIENTDC 标志位是否必要
3. 最小权限：普通用户不要给太多证书申请权限
4. 监控异常证书请求：监控异常的证书申请行为
5. 定期渗透测试：用 Certify/Certipy 测试 AD CS 配置
6. 分段防御：域管账号严格管控，用 PAM 堡垒机

八、总结

Certighost（CVE-2026-54121）是 AD CS 安全的一个经典案例：企业公钥基础设施本来是用来增强安全性的，但配置错误反而成了攻击入口。在企业域安全领域，AD CS 是最高价值的攻击面之一——一个配置错误的 CA，能让普通域用户直接变成域管。理解证书信任模型、PKINIT 认证、DCSync 攻击，是做企业域安全的基本功。在 SRC 挖洞实践中，企业内网的 AD CS 审计是赏金最高的方向之一——一个能拿域管的漏洞，对企业来说价值极高。