在受控Windows 11实验室环境中对RoguePlanet Microsoft Defender概念验证的验证报告，包括构建说明、Defender检测结果、风险评估和缓解建议。
本报告涉及公开描述的与 Microsoft Defender 相关的 RoguePlanet PoC 的验证。该技术在媒体上于2026年6月10日被描述为本地权限提升（LPE），本地用户可通过该技术获取 NT AUTHORITY\SYSTEM 权限。公开描述指出，该机制使用了 Microsoft Defender 在处理或扫描文件时使用的函数。
测试的目的在于确定该漏洞能否在受控实验室环境中准备和执行，并观察在最新的 Windows 11 系统上 Microsoft Defender 保护机制的行为。报告涵盖测试环境、更新状态、Microsoft Defender 配置、编译环境的准备、编译结果、Defender 响应以及风险缓解建议。
该测试为研究导向，在专用测试工作站上本地执行。结果应被视为对特定工件和特定环境配置行为的评估，而非对该技术所有可能变体的完全抵抗性确认。
分析材料中引用的来源：
Article:
https://thehackernews.com/2026/06/microsoft-defender-rogueplanet-zero-day.html
Public PoC repository:
MSYS2 installer source:
https://github.com/msys2/msys2-installer/releases/tag/nightly-x86_64
Visual Studio source:
PoC 在未加入 Active Directory 域、位于 WORKGROUP 工作组中的客户端工作站上执行。工作站上安装的操作系统为 Microsoft Windows 11 Home，版本 25H2，64 位架构。
| 参数 | 值 |
|---|---|
| 系统名称 | Microsoft Windows 11 Home |
| 版本 | Home |
| 系统版本 | 25H2 |
| OS 版本 | 10.0.26200 |
| 内部版本号 | 26200 |
| 架构 | x64 / 64-bit |
| 安装类型 | Client / Workstation |
| 主机名 | LAPTOP-80LPIEH2 |
| 设备制造商 | Lenovo |
| 设备型号 | Lenovo Legion Slim 5 16IRH8 |
| 处理器 | 12th Gen Intel(R) Core(TM) i5-12450H |
| 内存 | 32 GB |
在 PoC 执行当天，系统已安装 2026 年 6 月安全更新，以及 2026 年 5 月和 4 月的早期更新。这意味着测试是在安装了截至测试日期最新可用安全补丁的 Windows 11 25H2（内部版本 26200）系统上进行的。
| HotFixID | 更新类型 | 安装日期 |
|---|---|---|
| KB5094135 | Security Update | 10.06.2026 |
| KB5094126 | Security Update | 10.06.2026 |
| KB5087051 | Update | 14.05.2026 |
| KB5092762 | Security Update | 13.05.2026 |
| KB5054156 | Update | 28.04.2026 |
用于测试的工作站上 Microsoft Defender 防病毒处于活动状态，并以正常模式运行。保护服务已启动并已启用，防病毒保护、反间谍软件保护、行为监控和实时保护均处于活动状态。
| 参数 | 值 |
|---|---|
| AMProductVersion | 4.18.26050.15 |
| AMServiceVersion | 4.18.26050.15 |
| AMEngineVersion | 1.1.26050.11 |
| AMRunningMode | Normal |
| AMServiceEnabled | True |
| AntivirusEnabled | True |
| AntispywareEnabled | True |
| RealTimeProtectionEnabled | True |
| BehaviorMonitorEnabled | True |
| OnAccessProtectionEnabled | True |
| IoavProtectionEnabled | True |
| NISEnabled | True |
| NISEngineVersion | 1.1.26050.11 |
| IsTamperProtected | True |
| DefenderSignaturesOutOfDate | False |
| RebootRequired | False |
| IsVirtualMachine | False |
测试当天，Microsoft Defender 签名是最新的。防病毒、反间谍软件和 NIS 签名已于 2026 年 6 月 10 日 13:27:32 更新。
| 签名类型 | 版本 | 最后更新日期 |
|---|---|---|
| AntivirusSignatureVersion | 1.453.27.0 | 10.06.2026 13:27:32 |
| AntispywareSignatureVersion | 1.453.27.0 | 10.06.2026 13:27:32 |
| NISSignatureVersion | 1.453.27.0 | 10.06.2026 13:27:32 |
上次快速扫描于 2026 年 6 月 8 日 15:00:36 至 15:01:58 期间使用签名版本 1.451.323.0 执行。之前未执行全盘扫描或历史记录不可用，如 FullScanAge 值 4294967295 以及缺少全盘扫描开始和结束时间所示。
首次尝试编译 GitHub 仓库中的代码时因缺少 winternl.h 头文件而失败。消息指出系统缺少分析代码所需的完整 Windows SDK 头文件集。
图 1. 首次编译尝试时缺少 winternl.h 头文件错误。
代码还引用了其他与 Windows API 和 NT API 相关的头文件，包括 windows.h、Psapi.h、ntstatus.h、virtdisk.h、shlwapi.h、taskschd.h 和 bcrypt.h。因此，需要准备更完整的编译环境并安装适当的 SDK 组件。
图 2. 分析代码所需头文件列表片段
最初使用 MSYS2/MinGW-w64 准备编译环境。该环境提供适用于 Windows 的 GNU 工具，包括 gcc 和 g++ 编译器。MSYS2 中的包通过 pacman 管理，其作用类似于 Linux 上的 apt 或 Windows 上的 winget。
图 3. MSYS2 安装完成。
使用 pacman 安装了 MinGW-w64 GCC/G++ 工具链，即一组支持编译 Windows 下 C/C++ 代码的工具。该包包括 gcc 编译器、g++ C++ 编译器、链接器以及构建 Windows 环境应用程序所需的头文件和库。此尝试的目的是检查代码能否使用 MSYS2 中的开放工具链编译，而无需使用 Visual Studio。
图 4. 使用 pacman 安装 MSYS2/MinGW-w64 包。
安装后，尝试使用 g++ 编译代码。命令直接指定了源文件路径和生成的可执行文件路径。
C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe
Unicode 模式问题的第一个明显迹象是编译器有关字符类型不兼容的消息。日志包含错误，指出 const wchar_t* 或 wchar_t* 类型的值无法转换为 LPCSTR 或 LPSTR。这意味着代码将宽字符串传递给 Windows API 函数，而编译器选择了针对经典 ANSI 字符串的函数变体。
在 Windows API 中，许多函数存在两种变体：ANSI（带 A 后缀）和 Unicode（带 W 后缀）。例如，CreateFile 可映射为 CreateFileA 或 CreateFileW，RegOpenKeyEx 可映射为 RegOpenKeyExA 或 RegOpenKeyExW。A 变体期望 char* 或 LPCSTR 类型的参数，而 W 变体期望 wchar_t* 或 LPCWSTR 类型的参数。
在分析的情况中，代码使用了 L"..." 形式的字面量和 wchar_t 类型的缓冲区。同时，错误消息表明编译器选择了 GetModuleHandleA、RegOpenKeyExA、RegQueryValueExA、GetWindowsDirectoryA、CreateFileA 和 wsprintfA 等函数。这直接表明代码是为 Unicode 模式编写的，但编译命令未定义 UNICODE 和 _UNICODE。
因此，通过添加 UNICODE 和 _UNICODE 定义强制启用 Unicode 模式。更改后，没有显式后缀的 Windows API 函数应映射到带 W 后缀的变体，如 CreateFileW、RegOpenKeyExW、GetModuleHandleW 和 GetWindowsDirectoryW。部分错误在此更改后消失，证实了诊断的正确性。
C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe -DUNICODE -D_UNICODE
然而，在消除 Unicode 相关问题后，仍存在表明代码与 MinGW 存在更深层次不兼容性的错误。这些错误涉及，例如，FILE_BASIC_INFORMATION 和 FILE_RENAME_INFORMATION 结构的重复定义（在源代码和 MinGW 头文件中均有定义）。此外，MinGW 中可用的 FILE_RENAME_INFORMATION 版本与代码期望的版本不同，包括缺少 Flags 字段。
额外的错误还源于 g++ 编译器对类型（尤其是 enum 标志和函数指针）更严格的检查方式。这涉及，例如，VIRTUAL_DISK_ACCESS_MASK 和 ATTACH_VIRTUAL_DISK_FLAG 类型，以及将函数指针作为 void* 传递。因此，在不显著修改源代码的情况下，MinGW 被认为不适合编译此代码。
由于与 MinGW 的兼容性问题，准备了 MSVC 和 Windows SDK 环境。在 Visual Studio 安装程序中选择“使用 C++ 的桌面开发”工作负载，因为分析代码是使用 C/C++ 编写的原生 Windows 应用程序，并直接使用 Windows API 和 Windows SDK 组件。它不是一个 .NET、Python、Node.js 或 Web 应用程序项目，因此未安装与这些技术相关的组件。
图 5. 选定的 Visual Studio 工作负载和桌面 C++ 应用程序组件。
最重要的组件是 MSVC v143，即 Microsoft C/C++ 编译器，用于构建适用于 Windows 的 C/C++ 应用程序。之所以选择它，是因为之前使用 MinGW/G++ 编译的尝试导致与头文件、类型和 NT API 结构相关的兼容性错误。代码使用了特定于 Windows 的机制，因此最兼容的环境是 Microsoft 编译器以及 Windows SDK 提供的库。
还安装了 Windows 11 SDK。此组件包含使用 Windows 系统功能所需的头文件和库，包括 windows.h、winternl.h、winreg.h、processthreadsapi.h、virtdisk.h 以及在链接期间使用的 .lib 导入库。此外，保留了 C++ CMake 工具作为辅助组件，在分析更复杂的项目时很有用。
安装后，使用了 x64 Native Tools Command Prompt for VS Insiders——一个设置了正确路径的 CLI，包含 cl.exe 编译器、Windows SDK 和链接器库。
