文章总结： 本文分析AD域两个高危漏洞：KerberLoss(CVE-2026-25177)与ResetNightmare(CVE-2026-27912)，根源在于LDAP忽略特定Unicode字符及Kerberos改密流程缺少TGS-REQ校验。补丁早于公开超百天，但覆盖率仍是主要矛盾。攻击链需域内对象写权限的低权限账号，可重置目标密码。建议及时修补并收敛权限。 综合评分： 85 文章分类： 漏洞分析,威胁情报,恶意软件

Linux 系统中的 AD ResetNightmare (CVE-2026-27912) 和 KerberLoss (CVE-2026-25177) 漏洞

Ots安全

2026年9月12日 14:31 广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

威胁简报

恶意软件

漏洞攻击

2026 年 8 月 5 日，Semperis 安全研究员 Shai Laron 在 Black Hat 与 DEF CON 演讲之后公开了一份题为 Identity Crisis 的研究，里面是两个针对 Active Directory 与 Kerberos 的漏洞：KerberLoss（CVE-2026-25177）与 ResetNightmare（CVE-2026-27912）。微软早在三月的补丁日修掉了前一个，四月的补丁日修掉了后一个。两者的共同点只有一句话就能说完：Active Directory 对某些名字的校验，可以被绕过去。

真正值得写下来的不是这两个漏洞本身，而是它们各自的时间位置。KerberLoss 的补丁比研究公开早了一百四十八天，ResetNightmare 早了一百一十三天。在补丁发布那一刻，外界没有任何人知道这两个编号背后是什么。这与本号此前写过的 Chrome 在野零日、以及那份至今仍未证实的手稿级报告，是完全相反的两种处境。

本文把两份公告、两条 CVE 记录、一份 BinDiff 结果与一份 Linux 端的复现命令交叉核对，逐项标明哪些是一手事实，哪些是重建结果，哪些公开信息未说明。

完整披露时间线

Semperis 在博客里给出了逐日记录，以下为其原文日期的直接排布。

| 日期 | 事件 | | — | — | | 2025-11-26 | KerberLoss 被发现并报告给 MSRC | | 2025-12-17 | ResetNightmare 被发现并报告给 MSRC | | 2026-01-09 | MSRC 确认 ResetNightmare 成立 | | 2026-01-17 | MSRC 确认 KerberLoss 成立 | | 2026-03-10 | KerberLoss 补丁发布 | | 2026-04-14 | ResetNightmare 补丁发布 | | 2026-08-05 | 研究公开 | | 2026-08-26 | Semperis 发布新闻稿 | | 2026-08-31 | 秘鲁国家数字安全中心向本国机构转发 |

一、原因导致：LDAP 看不见的字符与跳过的一次校验

1.1 共同土壤：被完全忽略的 Unicode 字符

两个漏洞长在同一片土壤上。Semperis 的原句是 “There are Unicode characters that Active Directory’s LDAP server completely ignores.”。

研究者编译了三百八十五个不可见 Unicode 字符，逐一测试后分成三类：一百零六个可以被过滤，一部分被当作空白处理，还有一部分被域控的 LDAP 服务器完全忽略。被忽略的这一类，后果是用正常值去过滤时，带这些字符的值也可能被返回。

这个研究方向的起点来自 Yossi Sassi 关于 Active Directory 持久化技术的演讲，其中提到可以在对象属性里加入不可见的 Unicode 字符。Laron 在致谢里明确写了这一点。

换句话说，这不是一个新引入的缺陷，而是一个长期存在的解析特性，被用在了两个不同的校验环节上。

详情可参考这篇文章了解CVE-2026-27912：https://www.semperis.com/blog/identity-crisis-novel-vulnerabilities-leading-to-kerberos-downgrade-dos-and-full-domain-takeover/

1.2 KerberLoss：唯一性验证被绕开

2021 年微软针对 CVE-2021-42282 发布了 KB5008382，通过森林级的 dSHeuristics 属性强制 UPN、SPN 以及 SPN 别名的唯一性验证。这次的绕过点在于，不可过滤的字符可以让低权限用户创建出与既有值冲突、却通不过唯一性检查的名字。

Kerberos 里的 SPN 查找算法有一个关键行为：优先查找显式 SPN，只有在找不到显式 SPN 时才去查映射别名。这个优先级顺序，加上一个可以被塞进不可见字符的重复 SPN，构成了三种后果。

• 第一种是对 HOST 映射服务的拒绝服务。给一台机器加上带不可见字符的重复 SPN 之后，KDC 会把它当成显式 SPN，用这台机器的密钥去加密发往真正服务方的票证，对方解不开，客户端报 KRB_AP_ERR_MODIFIED。原文强调这个影响范围是全森林任意 HOST 映射服务。
• 第二种是 SPN 劫持，为 S4U 约束委派攻击铺路。
• 第三种是强制降级。创建完全重复的 SPN 会让域控返回 KDC_ERR_S_PRINCIPAL_UNKNOWN，客户端随后回退到 NTLM。原文的说法是可以强制森林内任意服务改用 NTLM，除非该环境已禁用 NTLM，那样的话结果就变成拒绝服务。

这第三种后果值得单独记一笔：KerberLoss 不直接中继凭据，但它能制造出让客户端放弃更强协议的局面，后续的 NTLM 中继风险是既有问题被重新打开，不是新问题。

1.3 ResetNightmare：改密流程里少了一次请求

ResetNightmare 的机制与不可见字符无关，它落在 Kerberos 协议流程的一个缺口上。

2021 年的 CVE-2021-42287 之后，微软在 PAC 里引入了 PAC_REQUESTOR_SID 字段，用来记录发起请求者的真实 SID，并且在 TGS-REQ（票据授予服务请求）阶段强制校验。域控从此不再信任票据里的客户端名字，只认 SID。这一改动让基于名字混淆的攻击基本失效。

但 Kerberos 改密协议（kpasswd，端口 464）不走常规路径。它的流程是 TGT-REQ 之后直接发 AP-REQ，中间没有 TGS-REQ。Semperis 的原句是 “this flow goes directly from a TGT-REQ to an AP-REQ, without a TGS-REQ in between.”。

既然校验挂在 TGS-REQ 上，而这条路径压根不经过 TGS-REQ，那道校验就不会发生。这就是 ResetNightmare 的名字来源，也是它能与 2021 年那批攻击相提并论的原因。

1.4 补丁证据：新增了一道身份校验

CravateRouge 对补丁前后两个版本的 kdcsrv.dll 做了 BinDiff，结果指向 KdcChangePassword 这个请求路径，而不是对象存储的访问路径。改动的核心是新增一个函数 KdcValidatePacUserSid()，在密码重置操作被允许继续之前插入一道身份与 PAC-SID 的校验分支，校验失败返回 STATUS_ACCESS_DENIED。

需要标明证据等级：这是基于二进制差异比对的伪代码重建，不是对原始补丁代码的阅读。函数名的存在与调用位置来自重建结果，微软未公开补丁源码。这一条在参考章也会重复标注。

不过从防御角度看，这个位置是合理的。缺陷的根源不是目录里能不能写入冲突的名字，而是改密请求没有被要求证明发起者身份，把校验补在改密入口上，正好对上了第三节第三小节描述的缺口。

二、漏洞触发：从一次属性写入到改掉别人的密码

2.1 四步复现的骨架

CravateRouge 在 Linux 上用一组命令行工具完整复现了这条链，演示环境是自建域。以下只描述步骤与命令骨架，不提供可直接运行的参数化脚本。

第一步，把目标账号（演示中是 Administrator）的 sAMAccountName 取值，写成受控账号的 userPrincipalName 属性值。

bloodyAD -H 192.168.100.3 -d bloody -u john -p 'Password123!'getobject'Administrator' --attr sAMAccountName distinguishedName: CN=Administrator,CN=Users,DC=bloody,DC=corpsAMAccountName: Administrator bloodyAD -H 192.168.100.3 -d bloody -u john -p 'Password123!'setobject john userPrincipalName -v Administrator[+] john's userPrincipalName has been updated

第二步，以 ptype=10 申请面向 kadmin/changepw 服务的 TGT 并存入凭据缓存。ptype=10 即 NT-ENTERPRISE，用来告诉 KDC 所提供的用户名是 UPN 类型，而不是默认的 sAMAccountName 类型（NT-PRINCIPAL，值为 1）。

badTGT 'kerberos+pw://bloody.corp\Administrator:[email protected]/?ptype=10' --ccache john.ccache --sname kadmin/changepw TGT stored in ccache file john.ccache Realm        :BLOODY.CORPSname        : kadmin/changepwUserName     :AdministratorUserRealm    :BLOODY.CORPStartTime    :2026-08-10 04:00:25+00:00EndTime      :2026-08-10 04:02:25+00:00RenewTill    :2026-08-10 04:02:25+00:00Flags        : renewable, pre-authent, forwardable, initial, enc-pa-repKeytype      :23Key          : vY2Etp/mzA7WT3x6BBnVPQ==EncodedKirbi :[...][+] Done!

第三步，把受控账号上伪造的 userPrincipalName 清掉。

bloodyAD -H 192.168.100.3 -d bloody -u john -p 'Password123!'setobject john userPrincipalName

第四步，用第二步拿到的凭据缓存向改密服务提交请求，改掉目标账号的密码。

badchangepw 'kerberos+ccache://BLOODY.CORP\Administrator:[email protected]''newAdminPwd1!'Password changed successfully!

演示中使用的工具包括一个 Active Directory 操作工具与两个 Kerberos 工具，本文不对其项目归属做断言，仅称为演示所用工具。

2.2 关键一步在第三步

这四步里，真正把攻击从失败变成成功的是第三步，也就是把伪造的 UPN 清掉。

保留 UPN 时，改密服务能同时按 UPN 和 sAMAccountName 找到两个对象，名字冲突会让它回到攻击者自己的账号上，充其量是改掉攻击者自己的密码。

清掉 UPN 之后，目录里再也没有谁的 UPN 等于票据上的那个名字。改密服务只能退回去按 sAMAccountName 解析，于是命中真正的目标账号。

Semperis 的描述里有一处细节值得注意：UPN 改动之后再拿这张票据去发 TGS-REQ，会收到 KDC_ERR_TGT_REVOKED。这张票据在正常路径上已经废了，但拿它去构造改密请求却依然有效。同一张票据在两条路径上的待遇不同，正是第三节第三小节那个缺口的直接体现。

2.3 为什么改的是自己的密码，结果改到了别人头上

把机制压缩成一句话：票据里的 PAC 记录的是攻击者自己的 SID，票据上的用户名却是目标的 sAMAccountName，而改密这条路径恰好不检查这两者是否一致。

正常情况下这不是问题，因为常规的服务票据申请（TGS-REQ）会做一致性校验，不一致就拒绝。改密路径跳过了这一步。第三步清 UPN 的操作，则是把目录里唯一能让名字对得上的攻击者账号移除，断掉改密服务回头找攻击者的退路。

一个边界要写清楚：这条链证明的能力是重置目标账号的密码，不是绕过认证本身。攻击者仍需持有受控账号的有效凭据，仍需满足第五节提到的权限前置。把”能重置域管密码”说成”无需任何凭据接管域”，是跨过了证据边界。

2.4 三个不能省略的前置条件

条件一：写权限或创建对象能力。 需要对域内任意用户或计算机对象有通用写权限，或者能创建用户或计算机对象，MachineAccountQuota 除外。

条件二：目标账号密码需满足最小密码年龄。 Semperis 指出目标账号的密码需满足默认的一天最小密码年龄，否则改密请求会被密码策略挡下。

这一条要格外小心。有些防御文章把”保持最小密码年龄为默认的一天”列成缓解措施，方向是对的，但它本质上是密码策略的副作用，不是为这个场景设计的安全控制。把它当成防御手段，等于把一次偶然的挡截当作防线，一旦有人调整策略就失效。真正该做的是条件一的权限收敛。

条件三：攻击者已知受控账号的凭据。 票据申请环节需要受控账号的密码或哈希，不存在无凭据利用。

三条合起来，准确的表述是：具备域内对象写权限的低权限账号，可以在不知道目标旧密码的前提下重置目标账号密码，包括域管理员账号。这个表述已经足够重，不需要再加码。

三、补丁分析与延伸议题

3.1 补丁早于公开，这本身就是结论

两个编号的补丁发布日期是 2026 年 3 月 10 日与 4 月 14 日，研究公开是 8 月 5 日。中间隔了一百四十八天与一百一十三天。

把这三个日期摆在一起，能得到几条确定结论：

• 补丁发布时，除微软与报告方外没有人知道细节，因此不存在补丁发布到研究公开之间的暴露窗口。这与本号此前写过的在野零日是完全不同的处境。
• 两个编号的在野利用标记与已公开披露标记均为否，MSRC 对利用可能性的判定都是 Exploitation Less Likely。这些是官方字段，可以直接引用。
• 反过来看，经过一百多天之后，仍有大量域控处于未修补状态。补丁可用性从来不是这类漏洞的主要矛盾，补丁覆盖率才是。

3.2 官方与发现方的评级分歧，两边都要记

Semperis 在 8 月 26 日的新闻稿里写得很直接：”Microsoft rated the ResetNightmare and KerberLoss vulnerabilities as Important Elevation of Privilege vulnerabilities in its severity-label system. Semperis rates both vulnerabilities as a SEVERE risk to organizations.”

分歧的根基不在技术判断，而在评价坐标系。微软的严重等级标签衡量的是漏洞本身的属性，Semperis 的 SEVERE 衡量的是资产在企业环境中的重要性。同一件事，一个说这个洞有多难打，一个说这个东西被打了会怎样。

两边都对，且不可互相替代。做补丁排期时应该同时看两个数：微软的等级决定技术紧急度，资产重要性决定业务紧急度。域控属于后者极高的那一类，因此这两个编号在实际排期里应当高于它们的 Important 标签所暗示的位置。

需要守住的一条边界：不得因为发现方用了域接管这个词，就反过来认定微软低估。微软的官方描述只到提升权限，这是 CNA 的定性口径，本文全篇沿用这一口径，域接管一词出现时一律标注为发现方表述。

3.3 五年里的第三次名字混淆

ResetNightmare 这个名字里的 Nightmare 不是随便取的，它指向 2021 年的 CVE-2021-42287，业界俗称 noPac。那一年的攻击手法是把机器账号的 sAMAccountName 改成域控账号的名字，再利用 Kerberos 的名字解析拿到高权限票据。

微软那次的修复方式是引入 PAC_REQUESTOR_SID，让域控不再信任票据上的客户端名字。这在 TGS-REQ 路径上做得很彻底。

四年多之后，Laron 找到的是那条没有被覆盖到的路径。改密协议不走 TGS-REQ，于是那道校验形同虚设。

这件事的结构性含义比单个漏洞更有价值：一个协议里存在多条并行的请求路径时，在其中一条路径上补齐的校验，不会自动覆盖到其他路径。每一次修补都应当问一句，同一个动作还有没有别的入口。

从这个角度看，这次补丁把校验补在 KdcChangePassword 这个具体入口上，是对症的，但它是否覆盖了改密的其他入口，公开信息未说明。

4.结束语

这两个漏洞的技术门槛都不算高，难的是发现它们的视角。给自己账号改一个 UPN 属性，请求一张票据，再把属性改回去，三步之后就能重置域管理员的密码。其中没有任何一步需要破解、需要内存破坏、需要绕过杀软。它利用的是协议路径之间的不对称，以及目录服务对某些字符的宽容。

补丁提前了一百多天，流程上是成功的，MSRC 在二十三天内确认了其中一个编号，负责任披露的每一个环节都跑通了。可这仍然不能保证域控已经打上补丁。从补丁可用到补丁装上之间的那段距离，才是这两个编号真正的风险所在，而这段距离与漏洞本身的技术复杂度无关。

身份系统里有一类权限，看上去只是改个属性，实际等价于改认证结果。这类权限的数量通常远超管理员的预期，也最难清理。把 UPN 与 SPN 的写入权当作特权来对待，比记住这两个 CVE 编号更有长期价值。

八、参考

https://cravaterouge.com/articles/resetnightmare/

https://www.semperis.com/blog/identity-crisis-novel-vulnerabilities-leading-to-kerberos-downgrade-dos-and-full-domain-takeover/

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-27912

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-25177

https://nvd.nist.gov/vuln/detail/CVE-2026-27912

https://nvd.nist.gov/vuln/detail/CVE-2026-25177

END

公众号内容都来自国外等平台- 搜索的内容通过结合编写 –

 提供整洁 – 广告已关

公众号 | AnQuan7 (Ots安全)

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Ots安全 《Linux 系统中的 AD ResetNightmare (CVE-2026-27912) 和 KerberLoss (CVE-2026-25177) 漏洞》