2020 年 8 月补丁日，微软修了一个 Netlogon 的漏洞：CVE-2020-1472。几个月后利用代码公开，勒索软件开始拿它打域控。安全圈给它起名 ZeroLogon——利用时会把目标机器账户的密码设成空。
对域环境来说，这是最糟的一类漏洞：不需要账号，不需要钓鱼，只要能连到域控的 RPC 端口。
背景：Netlogon 与机器账户#
域内的计算机用机器账户（形如 COMPUTER$）和域控通信，Netlogon 协议负责建立这条安全通道。机器账户的密码由系统自动维护，客户端和域控各存一份，用来证明“我是这台机器”。
这套认证建立在 Netlogon 的挑战-应答之上：双方各自用共享密钥算一段密文，对得上就认为身份成立。ZeroLogon 的问题，就出在这个握手的加密实现里。
漏洞原理：全零 IV 的 AES-CFB8#
点到为止。Netlogon 使用 AES-CFB8 做认证加密，而实现里把初始化向量固定成了全零。CFB8 的特性是：当输入全为零时，输出也有一定概率全为零。
攻击者反复发起认证，每次都期望“密文全零”被接受。大概 256 次里会有一次命中。这不是猜密码，是撞一个密码学实现里的概率缺陷。
一旦通过，攻击者就以某台机器账户的身份连上域控，并调用修改密码的接口，把该账户密码置空。接着用这个空密码账户做 DCSync，导出域内所有哈希。
从“能访问域控的 RPC 端口”到“域管理员”，中间没有第二道坎。这也是它被勒索软件当成标准第一步的原因。
它常被列进域环境的高优先级项，原因也在这里：攻击者不需要先拿到任何账号，前期也不会留下登录成功的记录。
影响范围#
| 条件 | 说明 | 风险 |
|---|---|---|
| 域控未打 2020 年 8 月及之后的累积更新 | 最直接的暴露 | 高 |
| 已打补丁但未启用强制模式 | 兼容模式下仍可能被利用 | 中高 |
| 域控 RPC 对办公网或公网开放 | 攻击面被放大 | 高 |
| 只读域控（RODC） | 同样需要评估 | 中 |
具体的补丁编号与启用时间点请以微软安全公告为准。不同 Windows 版本的更新节奏不完全一样，“我打了补丁”这句话要落到具体 KB 和安装日期上。
域信任关系也要看一眼。子域、林信任、只读域控，任何一条通道没打补丁，攻击者都能从边缘摸到核心。清单上写“域控已修复”是不够的，要写到每一台。
检测#
# 1. 补丁后的强制模式状态
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' |
Select-Object FullSecureChannelProtection, VulnerableChannelAllowList
# 2. 机器账户密码近期是否被大量改动（事件 4742）
Get-WinEvent -FilterHashtable @{
LogName='Security'; Id=4742; StartTime=(Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Message -First 20
# 3. 打开 Netlogon 调试日志（排查完记得关）
nltest /dbflag:0x2080ffff
第一条看的是“修完没有”。FullSecureChannelProtection 为 1 才说明强制模式生效；如果它缺失或为 0，补丁打了也还留着口子。
第二条是核心信号。正常环境下机器账户密码按周期轮换，不会在短时间内被大量重置，更不会出现“密码被设为空”的 4742。看到同一时间段内几十条 4742，先别管业务，直接隔离域控。
第三条会生成 netlogon.log，里面记录 NetrServerAuthenticate3 的调用与结果码，能看到来源机器名。这个日志默认不开，排查时临时打开，完事关掉，否则磁盘很快被写满。
还有两个辅助信号：域控的 445、135 端口有没有来自异常网段的连接；以及安全日志里 4624 的登录类型 3 是否出现大量空密码机器账户登录。
看 4742 时要读 Subject 与 Target 两段。正常的机器账户改密，操作者是机器自己或授权的管理员；异常情况下，Subject 往往是匿名或陌生的机器账户，Target 是域控自己。这个区别比事件数量更能说明问题。
修复与缓解#
- 给所有域控打齐累积更新，包括只读域控。补丁要一台一台确认，别信“域内已统一推送”。
- 确认强制模式已生效。2021 年 2 月之后的更新默认启用强制，但被手动关过的环境要复查。补丁与强制是两段式，只做前一半，等于没修完。
- 处理遗留设备。老式打印机、NAS、非 Windows 设备可能还在用不安全的通道，用
VulnerableChannelAllowList做例外，而不是整体关掉强制。 - 网络侧收口。域控的 RPC 端口不对互联网和办公网开放，只允许管理网段。
顺序上，先补丁、再开强制、最后收网络。反过来做，你会先炸掉兼容性，再被迫关掉强制，等于白折腾一轮。
# 启用强制模式（先在测试域验证遗留设备）
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' `
-Name FullSecureChannelProtection -Value 1 -Type DWord
# 只给确需兼容的老设备开例外
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' `
-Name VulnerableChannelAllowList -Value 'PC-OLD01$' -Type MultiString
Restart-Service Netlogon
强制模式会让不兼容的旧设备直接掉域。先在测试域跑一周，把所有例外列出来、走审批，再推生产。回滚方法是把 FullSecureChannelProtection 改回 0，但那等于把洞重新打开。
验证#
验证不是跑一遍命令就结束。把补丁号、强制模式状态、例外清单、验证时间写进同一份记录，下一次审计时它就是证据。
Get-ItemProperty确认FullSecureChannelProtection=1，例外列表为空或每一条都有审批记录。- 用一台普通成员机执行
nltest /sc_query:DOMAIN，应正常通过，说明兼容性没被破坏。 - 复查 4742：不再出现异常的批量重置。
- 观察 Netlogon 事件 5827、5828、5829，这些是被拒绝的脆弱连接记录，出现就说明还有设备在尝试旧通道。
- 做一次域控还原演练，确认恢复后强制模式仍然生效，别让备份把配置带回旧状态。
结论#
- ZeroLogon 的门槛是“网络可达”，不是“有账号”。
- 打补丁只是第一步，强制模式没开等于没修完。
- 最可靠的检测信号是 4742 的异常机器账户密码变更。
- 遗留设备用白名单管理，不要为了兼容整体关掉强制。
- 域控的网络暴露面要单独治理，这是所有域内攻击的共同前提。
完