Certighost漏洞深度解析:一枚证书如何撕开整个Windows域的防线

发布时间:2026/7/30 3:25:40
Certighost漏洞深度解析:一枚证书如何撕开整个Windows域的防线 2026年7月的安全圈被一颗重磅炸弹震动了。安全研究员H0j3n与Aniq Fakhrul在7月24日公开披露了一个被命名为Certighost的高危漏洞官方编号CVE-2026-54121。这个藏在Active Directory证书服务里的缺陷让任何一个普通域用户都有了冒充域控制器的可能——而域控制器向来被视为Windows企业网络中最不可触碰的核心资产。微软在7月14日的补丁星期二中已经提前发布了修复方案但十天后PoC代码的公开上线意味着留给企业安全团队反应的时间窗口正在急速收窄。为什么这个漏洞值得所有人警惕要理解Certighost的破坏力得先明白AD CS在企业架构里扮演什么角色。Active Directory证书服务负责签发和管理数字证书这些证书支撑着域内Kerberos身份验证的运转。换句话说谁拿到了域控制器的证书谁就等于拿到了开启整栋大楼的万能钥匙。过去业界对AD CS安全的关注大多集中在模板配置错误上比如ESC1到ESC15那一系列攻击路径。防御者的思维惯性是只要模板ACL收紧了、SAN标志关闭了、ENROLLEE权限审计到位了证书服务就是安全的。Certighost的出现彻底打破了这种幻觉——它压根不依赖任何配置失误而是钻了协议设计层面的空子。一个普通域用户不需要管理员权限不需要任何人点击钓鱼链接甚至不需要提前控制任何高价值机器。只要网络能触达到证书颁发机构就能完成从路人甲到域主宰的跨越。微软给这个漏洞的CVSS评分是8.8归类为CWE-285授权不当但数字背后隐藏的真实风险远比分数本身更骇人。Chase回退被忽视的十余年旧机制Certighost的入口藏在AD CS证书注册流程里一个鲜为人知的回退机制中研究人员称之为chase。这个机制的本意是善意的——当证书颁发机构在签发证书时无法直接解析终端实体的身份信息它允许请求方指一条路告诉CA该去哪台机器上查询缺失的身份数据。问题就出在这条指路上。请求中包含两个关键属性cdcClient DC和rmdRemote Machine。cdc告诉CA应该联系哪台主机rmd则指定了需要解析的主体对象。CA收到请求后会主动向cdc指向的地址发起SMB和LDAP连接查询rmd对应的身份信息然后把查到的数据写进即将签发的证书里。听起来合理对吧但致命的疏漏在于——CA从来没有验证过这条指路是否真的指向一台合法的域控制器。它就像一个过于轻信的门卫有人告诉它去那边查一下它就真的去了完全不核实对方是不是在撒谎。攻击者正是利用了这一点。他们在自己控制的机器上搭建伪造的LDAP和LSA服务然后在证书请求里填入自己机器的地址作为cdc目标。CA乖乖地跑过来查询攻击者的假服务就返回目标域控制器的objectSid和dNSHostName。CA拿到这些数据以为是权威目录信息直接写进了证书的身份字段里包括强映射的SID和DNS标识。证书签发完成验证通过目标域控制器被成功克隆到了攻击者手中。从一张证书到全域沦陷攻击链的全貌整个利用链条的精妙之处在于全程使用的都是合法协议不触发EDR的典型检测规则。攻击者不需要什么0day漏洞利用技巧只需要对AD CS的工作方式有足够了解。第一步攻击者利用默认的ms-DS-MachineAccountQuota设置创建一台计算机账户——这个配额默认是10意味着任何普通域用户都能合法创建最多10台机器账户。有了这台自己控制的机器账户攻击者就获得了一个有效的域主体身份。第二步在这台机器上部署恶意的LDAP和SMB/LSA监听服务端口分别是389和445。同时准备好证书请求在请求中精心构造cdc和rmd属性把cdc指向自己的恶意服务地址rmd指向想要冒充的目标域控制器。第三步向企业CA提交证书注册请求。CA在处理请求时触发chase回退按照cdc的指引连接到攻击者的恶意服务。攻击者的服务 relay CA的认证挑战到真正的域控制器Netlogon接口同时返回目标DC的objectSid和dNSHostName。CA验证通过签发一张带有域控制器身份的证书。第四步攻击者拿着这张证书通过PKINIT进行Kerberos认证。由于证书里的身份是域控制器认证系统完全信任。域控制器账户天然拥有目录复制权限攻击者接下来就可以执行DCSync操作把krbtgt账户的哈希值拖出来。到了这一步游戏基本结束了。有了krbtgt哈希攻击者可以铸造Golden Ticket伪装成域内任何用户包括域管理员。整个Active Directory域就此沦陷。研究人员发布的概念验证工具certighost.py已经把这个流程完全自动化了从创建机器账户、部署恶意监听、构造请求到提取证书和Kerberos票据一键完成。微软的修复与补丁背后的技术细节微软在2026年7月14日的安全更新中修复了这个漏洞核心改动集中在certpdef.dll这个AD CS企业策略模块中。研究人员通过对补丁前后二进制文件的逆向分析发现了几个关键变化。补丁引入了一个全新的验证函数CRequestInstance::_ValidateChaseTargetIsDC还有一个辅助函数CRequestInstance::_ExtractBaseDNForDCSearch。在7月之前的版本中CA会直接执行chase查找而补丁之后CA在跟随cdc目标之前会先向Active Directory查询确认这个目标是否真的是一台带有SERVER_TRUST_ACCOUNT标志的域控制器并进行SID一致性比对。简单来说门卫终于学会了核实身份。它不再轻信请求者提供的指路信息而是自己先去目录里查证一下对方说的是不是真话。不过这里有个值得注意的细节。研究人员发现这个新的验证逻辑被一个内部功能开关Feature_3185813818控制。这意味着在某些情况下如果这个功能开关没有激活系统可能会回退到旧的行为模式。虽然微软默认会启用这个保护机制但企业在打补丁后最好还是验证一下功能状态确保防护真正生效。受影响的环境范围相当广泛涵盖了从Windows Server 2012到Windows Server 2025的多个版本包括Server Core变体以及Windows 10的1607和1809版本。不过需要强调的是真正存在实际风险的是那些运行了企业CA角色的系统。一台普通的成员服务器即便操作系统版本在受影响列表里只要没有部署AD CS就不会因为这个漏洞而被直接利用。防御建议不只是打补丁那么简单打补丁是治本之策没有任何商量余地。所有运行AD CS角色的证书颁发机构无论是不是域控制器都应该立即安装2026年7月的安全更新。这一点怎么强调都不过分。但在补丁落地之前或者作为补丁之外的纵深防御措施还有几件事可以做。把ms-DS-MachineAccountQuota设置为零可以阻止普通用户创建新的计算机账户。这虽然不能修复漏洞本身但能切断攻击链中的一个关键环节。当然在修改这个设置之前需要评估对现有域加入操作的影响。在CA主机上监控出站SMB和LDAP连接。如果发现CA试图连接到一个非域控制器的系统尤其是连接目标出现在证书请求的cdc属性中那很可能就是攻击正在发生的信号。审查证书请求日志留意包含异常cdc和rmd属性的请求。正常的企业证书注册流程很少会用到这些属性出现它们本身就值得警惕。把CA和域控制器一样视为Tier 0资产。很多企业把证书服务当成后台基础设施来管理补丁优先级排得很低。Certighost告诉我们CA一旦被攻破后果和域控制器被攻破没什么两样。收紧证书模板的注册权限确保只有真正需要的人才能获得证书签发资格。同时对历史上已经签发的域控制器证书做一次全面审计。如果发现有可疑的证书签发记录应该按照域沦陷事件来处理而不是当作普通的PKI异常。写在最后Certighost不是第一个针对AD CS的高危漏洞也不会是最后一个。从2022年的CVE-2022-26923到今天的CVE-2026-54121这一系列事件反复证明了一个道理证书基础设施的安全不能只看密码学强度身份解析路径、属性所有权、权威查找来源、模板策略、SID绑定机制每一个环节都可能成为突破口。如今PoC代码已经在GitHub上公开从代码发布到大规模扫描利用之间的时间窗口通常只有几小时到几天。对于已经部署了企业CA的组织来说2026年7月的这枚补丁不是建议安装而是必须立即安装。证书服务的安全从来都不是可有可无的选修课。当一张伪造的证书可以让你变成域控制器的时候这门课就变成了生死攸关的必修课。