今年微软 5 月 Patch Tuesday 刚落地,匿名安全研究员 Nightmare-Eclipse(亦称 Chaotic Eclipse)就甩出了两个新的 Windows 零日漏洞——这是该研究者今年公开的第五个零日。第一个漏洞代号 YellowKey,能绕过 BitLocker 全磁盘加密;第二个则是 SYSTEM 级提权。两个漏洞组合起来,意味着攻击者可以从物理接触一路打穿到最高权限,而加密保护形同虚设。
YellowKey:一根 USB 就能拆掉 BitLocker 的门锁
Nightmare-Eclipse 称 YellowKey 是"他发现的最疯狂的漏洞之一"。核心路径极其简洁:将特定文件加载到 USB 驱动器,插入目标机器,BitLocker 加密即被绕过。
BitLocker 的设计依赖 TPM 和启动验证链——正常流程下,系统引导组件被度量存入 TPM,密钥只在度量值匹配时释放。但 YellowKey 说明这条链上存在一个可被 USB 介入打断的环节。攻击者不需要网络访问、不需要登录凭据,只需要物理接触和一根 U 盘。
这让人联想到历史上几类 BitLocker 绕过手法:
- 冷启动攻击:从内存中提取残留的加密密钥。
- TPM 旁路:通过 DMA 接口(如 Thunderbolt)直接读取 TPM 释放的密钥。
- 启动配置篡改:修改引导配置数据(BCD)使 BitLocker 进入恢复模式,再利用弱恢复密码。
YellowKey 的 USB 载荷路径暗示它可能落在第三类——通过某种引导阶段的文件加载机制,改变了 BitLocker 的密钥释放决策。具体技术细节研究者尚未完全公开,但"特定文件 + USB"这个极低门槛的组合,已经足够让所有依赖 BitLocker 的部署重新审视自己的防线。
SYSTEM 提权:从绕过到接管
第二个零日是 SYSTEM 级提权。BitLocker 绕过让攻击者能读取磁盘内容,但如果目标机器上还有其他防线(如账户权限隔离),提权漏洞则把这些防线也一并推倒。
SYSTEM 是 Windows 最高本地权限,等价于 Linux 的 root。拿到 SYSTEM,攻击者可以:
- 安装内核级驱动或持久化后门
- 修改安全策略、关闭审计日志
- 读取所有用户凭据(包括域缓存的哈希)
- 以该机器为跳板横向移动
两个漏洞叠加的攻击链路:物理接触 → USB 插入 → BitLocker 绕过 → 获取磁盘内容 → 利用提权漏洞 → SYSTEM 权限 → 持久控制。链路短、依赖少、门槛低。
防御实操:现在能做的硬ening
微软尚未发布针对这两个零日的补丁。在补丁到达之前,以下措施可以缩小攻击面。每一条都附有可直接运行的命令或配置。
1. 强化 BitLocker 启动验证
最关键的一步:启用 BitLocker 的 TPM+PIN 模式,而非仅 TPM 模式。仅 TPM 模式下,密钥在度量匹配时自动释放,攻击者只要能篡改引导流程就可能拿到密钥;加上 PIN,即使引导链被篡改,攻击者仍需输入 PIN 才能解锁。
# 查看当前 BitLocker 状态
manage-bde -status C:
# 如果当前仅使用 TPM,添加 PIN 保护器
# 先创建 PIN(示例:变量 $pin 在交互式输入时使用)
$pin = Read-Host -AsSecureString -Prompt "输入 BitLocker PIN"
Manage-BDE -Protectors -Add C: -TPMAndPIN $pin
# 确认保护器列表
manage-bde -protectors -get C:
注意:添加 PIN 后每次开机需手动输入,对无人值守服务器不友好。对服务器场景可考虑 TPM+启动密钥(USB 上的密钥文件),但需物理保管该 USB。
2. 禁用未使用的 USB 存储驱动
YellowKey 的攻击入口是 USB 存储设备。在不需要 USB 存储的机器上(尤其是固定办公终端、服务器),直接禁用 USB 存储类驱动是最干净的阻断:
# 禁用 USB 存储驱动(需管理员权限)
# 方法一:通过 Group Policy 注册表项
$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices"
if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force }
New-ItemProperty -Path $regPath -Name "Deny_All" -Value 1 -PropertyType DWord -Force
# 方法二:直接禁用 usbstor 驱动
# 查找 usbstor.inf 对应的类 GUID
$usbstorPath = "HKLM:\SYSTEM\CurrentControlSet\Services\USBSTOR"
Set-ItemProperty -Path $usbstorPath -Name "Start" -Value 4 -Type DWord
# 验证:插入 USB 存储设备应无法识别
# 恢复命令(需要时):
# Set-ItemProperty -Path $usbstorPath -Name "Start" -Value 3 -Type DWord
3. 启用 BitLocker 恢复密码的 AD/Entra ID 备份
如果 BitLocker 被迫进入恢复模式,恢复密码是唯一的救命钥匙。确保恢复密码已备份到 Active Directory 或 Microsoft Entra ID,否则一旦 TPM 度量不匹配且 PIN 丢失,磁盘数据将不可恢复:
# 检查当前保护器中是否包含 RecoveryPassword
$protectors = manage-bde -protectors -get C:
$protectors | Select-String "Recovery Password"
# 强制备份恢复密钥到 Entra ID(适用于 Azure AD 加入的设备)
# 需要设备已加入 Entra ID
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId (Get-BitLockerKeyProtector -MountPoint "C:" | Where-Object KeyProtectorType -eq RecoveryPassword).KeyProtectorId
# 对于 AD 备份,确认 GPO 已配置:
# Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption
// > Choose how BitLocker-protected operating system drives can be recovered
// > Save BitLocker recovery information to Active Directory Domain Services
4. 提权漏洞的临时监测
在补丁发布前,无法从根本上堵住 SYSTEM 提权路径,但可以加强异常提权行为的监测。以下 PowerShell 脚本定期检查是否有非预期进程以 SYSTEM 身份运行、或出现可疑的令牌操作:
# 提权异常快速检查脚本(保存为 check-privilege-abuse.ps1)
# 可加入计划任务每 30 分钟运行一次
$suspiciousPatterns = @(
"cmd.exe", # SYSTEM 下意外出现的 cmd
"powershell.exe", # SYSTEM 下意外出现的 PowerShell
"whoami.exe", # SYSTEM 下执行 whoami(提权验证行为)
"net.exe", # SYSTEM 下执行 net user/group 操作
"psexec.exe" # PsExec 远程执行
)
$systemProcesses = Get-Process | Where-Object {
try {
$owner = (Get-WmiObject Win32_Process -Filter "ProcessId=$($_.Id)").GetOwner()
$owner.User -eq "SYSTEM"
} catch { $false }
}
$alerts = $systemProcesses | Where-Object {
$_.ProcessName -in $suspiciousPatterns
}
if ($alerts) {
$body = $alerts | ForEach-Object {
"进程: $($_.ProcessName) | PID: $($_.Id) | 时间: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')"
} | Out-String
# 写入本地日志
Write-EventLog -LogName Application -Source "PrivilegeMonitor" -EntryType Warning -EventId 9001 -Message $body
# 也可发送邮件或 webhook 通知
Write-Warning "检测到可疑 SYSTEM 进程: $body"
} else {
Write-Output "$(Get-Date) - 未检测到可疑 SYSTEM 进程"
}
# 注册自定义事件日志源(首次运行需执行一次)
if (-not (Get-EventLog -LogName Application -Source "PrivilegeMonitor" -Newest 1 -ErrorAction SilentlyContinue)) {
New-EventLog -LogName Application -Source "PrivilegeMonitor"
}
# 创建计划任务每 30 分钟运行
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\check-privilege-abuse.ps1"
$trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 30)
Register-ScheduledTask -TaskName "PrivilegeAbuseMonitor" -Action $action -Trigger $trigger -User "SYSTEM" -RunLevel Highest
风险边界与现实取舍
| 措施 | 防护效果 | 代价 |
|---|---|---|
| TPM+PIN | 阻断自动密钥释放,直接对抗 YellowKey 类绕过 | 开机需手动输入 PIN,无人值守场景需额外方案 |
| 禁用 USB 存储 | 切断 USB 载荷入口 | 无法使用合法 USB 设备,运维灵活性下降 |
| 恢复密码备份 | 不防绕过,但保证恢复能力 | 需 AD/Entra ID 基础设施 |
| 提权监测 | 不防漏洞,但缩短发现时间 | 误报需调优,脚本本身需安全保管 |
几个需要正视的现实:
- 物理接触是前提:YellowKey 需要插入 USB,意味着攻击者必须能物理接触目标机器。对高安全环境(机房、锁柜部署),物理门槛本身就是一层防线;对开放办公环境,物理接触几乎无法阻止。
- 补丁才是根解:所有 hardening 都是缩小窗口,不是封堵漏洞本身。关注微软后续补丁公告,一旦发布立即部署。
- 组合攻击的杀伤力远超单点:BitLocker 绕过 + SYSTEM 提权的组合意味着"加密 + 权限隔离"双防线同时失效。防御设计不能只加固一层。
检查清单
在补丁到达前,逐项确认:
- ✅ BitLocker 是否启用 TPM+PIN(而非仅 TPM)?
- ✅ 不需要 USB 存储的机器,usbstor 驱动是否已禁用?
- ✅ BitLocker 恢复密码是否已备份到 AD 或 Entra ID?
- ✅ 是否有提权异常监测机制在运行?
- ✅ 高价值机器是否有物理访问控制(机柜锁、安全区域)?
- ✅ 是否订阅了微软安全更新通知,准备第一时间部署补丁?
Nightmare-Eclipse 今年已公开五个零日,节奏还在加快。这不是偶发事件,而是持续的安全压力。BitLocker 和 Windows 权限模型是数亿设备的安全基石——当基石出现裂缝,硬ening 和快速补丁响应是唯一现实的应对。