Отчёт о валидации PoC RoguePlanet для Microsoft Defender

Цель и область отчёта

Этот отчёт касается валидации публично описанного PoC RoguePlanet, связанного с Microsoft Defender. Описанная техника была представлена в СМИ 10 июня 2026 года как локальное повышение привилегий (LPE), при котором локальный пользователь может получить привилегии NT AUTHORITY\SYSTEM. В публичных описаниях указывалось, что механизм использует функции, применяемые Microsoft Defender при обработке или сканировании файла.

Целью теста было определить, можно ли подготовить и выполнить эксплойт в контролируемой лабораторной среде, а также наблюдать, как механизмы защиты Microsoft Defender ведут себя в актуальной системе Windows 11. Отчёт охватывает тестовую среду, статус обновлений, конфигурацию Microsoft Defender, подготовку среды компиляции, результат компиляции, реакцию Defender и рекомендации по снижению рисков.

Тест носил исследовательский характер и выполнялся локально на выделенной тестовой рабочей станции. Результаты следует интерпретировать как оценку поведения конкретного артефакта и конкретной конфигурации среды, а не как полное подтверждение устойчивости ко всем возможным вариантам этой техники.

Источники, упомянутые в проанализированном материале:

• Статья:

  https://thehackernews.com/2026/06/microsoft-defender-rogueplanet-zero-day.html

• Публичный репозиторий PoC:

  https://github.com/MSNightmare/RoguePlanet/tree/main

• Источник установщика MSYS2:

  https://github.com/msys2/msys2-installer/releases/tag/nightly-x86_64

• Источник Visual Studio:

  https://visualstudio.microsoft.com/insiders/?rwnlp=pl

Тестовая среда

PoC выполнялся на клиентской рабочей станции, работающей вне домена Active Directory, в рабочей группе WORKGROUP. Операционная система, установленная на рабочей станции, — Microsoft Windows 11 Home, версия 25H2, 64-битная архитектура.

На день выполнения PoC в системе были установлены обновления безопасности за июнь 2026 года, а также более ранние обновления за май и апрель 2026 года. Это означает, что тест проводился на актуальной системе Windows 11 25H2, сборка 26200, после установки последних доступных обновлений безопасности на дату теста.

Конфигурация Microsoft Defender

Антивирус Microsoft Defender был активен на рабочей станции, использовавшейся для теста, и работал в обычном режиме. Служба защиты была запущена и включена, а защита от вирусов, защита от шпионского ПО, мониторинг поведения и защита в реальном времени были активны.

На день теста сигнатуры Microsoft Defender были актуальными. Сигнатуры антивируса, антишпионского ПО и NIS были обновлены 10.06.2026 в 13:27:32.

Последнее быстрое сканирование было выполнено 08.06.2026 в период с 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

Первоначально для подготовки среды компиляции использовался MSYS2/MinGW-w64. Эта среда предоставляет инструменты GNU для Windows, включая компиляторы gcc и g++. Пакеты в MSYS2 управляются с помощью pacman, который выполняет роль, аналогичную apt в системах Linux или winget в Windows.

Рисунок 3. Завершение установки MSYS2.

С помощью pacman был установлен набор инструментов MinGW-w64 GCC/G++, то есть набор инструментов, обеспечивающий компиляцию кода C/C++ для Windows. Пакет включает, среди прочих компонентов, компилятор gcc, компилятор g++ для C++, компоновщик, а также заголовки и библиотеки, необходимые для сборки приложений, работающих в среде Windows. Целью этой попытки было проверить, можно ли скомпилировать код с использованием открытого набора инструментов, доступного в MSYS2, без использования Visual Studio.

Рисунок 4. Установка пакетов MSYS2/MinGW-w64 с помощью pacman.

После установки была предпринята попытка скомпилировать код с помощью g++. Команда напрямую указывала путь к исходному файлу и путь к результирующему исполняемому файлу.

C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe

Проблема режима Unicode

Первым значительным признаком проблемы режима 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. Кроме того, версия FILE_RENAME_INFORMATION, доступная в MinGW, отличалась от ожидаемой кодом, включая отсутствие поля Flags.

Дополнительные ошибки также возникли из-за более строгого подхода компилятора g++ к типам, особенно к флагам перечислений и указателям на функции. Это касалось, в частности, типов VIRTUAL_DISK_ACCESS_MASK и ATTACH_VIRTUAL_DISK_FLAG, а также передачи указателей на функции как void*. В результате MinGW был признан непригодным для компиляции этого кода без значительных изменений исходного кода.

5. Переход на MSVC и Windows SDK

Из-за проблем совместимости с MinGW была подготовлена среда MSVC и Windows SDK. В установщике Visual Studio была выбрана рабочая нагрузка «Разработка классических приложений на C++», поскольку анализируемый код представлял собой нативное приложение Windows, написанное на C/C++ и напрямую использующее Windows API и компоненты Windows SDK. Это не был проект .NET, Python, Node.js или веб-приложения, поэтому компоненты, связанные с этими технологиями, не устанавливались.

Рисунок 5. Выбранная рабочая нагрузка Visual Studio и компоненты для классических приложений C++.

Наиболее важным компонентом был MSVC v143 — компилятор Microsoft C/C++, предназначенный для создания приложений C/C++ для Windows. Он был выбран потому, что более ранняя попытка компиляции с помощью MinGW/G++ вызвала ошибки совместимости, связанные с заголовками, типами и структурами NT API. Код использовал специфичные для Windows механизмы, поэтому наиболее совместимой средой был компилятор Microsoft вместе с библиотеками, предоставляемыми Windows SDK.

Также был установлен Windows 11 SDK. Этот компонент содержит заголовки и библиотеки, необходимые для использования системных функций Windows, включая windows.h, winternl.h, winreg.h, processthreadsapi.h, virtdisk.h и библиотеки импорта .lib, используемые при компоновке. Кроме того, в качестве вспомогательного компонента были сохранены инструменты CMake для C++, полезные при анализе более сложных проектов.

После установки использовалась командная строка x64 Native Tools Command Prompt for VS Insiders — интерфейс командной строки с корректно заданными путями для компилятора cl.exe, Windows SDK и библиотек компоновщика.

Рисунок 6. Запуск x64 Native Tools Command Prompt for VS Insiders.

6. Компиляция с использованием MSVC

После перехода на MSVC код продвинулся значительно дальше в процессе сборки. Первая команда по-прежнему возвращала ошибки, связанные с сопоставлением функций Windows API с вариантами ANSI, поэтому потребовалось добавить определения UNICODE и _UNICODE также и при компиляции MSVC.

cl /EHsc RoguePlanet.cpp -o rogue.exe

Рисунок 7. Попытка компиляции с использованием MSVC без полной настройки Unicode и компоновки.

После добавления переключателей Unicode код обрабатывался дальше, и ошибки совместимости заголовков и типов сменились ошибками компоновщика LNK2019. Это означало, что компилятор уже мог создать объектный файл, в то время как компоновщик ещё не получил все библиотеки импорта, требуемые используемыми функциями Windows API.

cl /EHsc /DUNICODE /D_UNICODE RoguePlanet.cpp /Fe:rogue.exe

Рисунок 8. Ошибки компоновщика LNK2019 для функций Windows API.

Ошибки компоновщика касались таких функций, как CreateProcessAsUserW, OpenProcessToken, AdjustTokenPrivileges, DuplicateTokenEx, GetTokenInformation, LookupPrivilegeValueW, RegOpenKeyExW и RegQueryValueExW. Эти функции связаны с токенами безопасности, привилегиями, запуском процессов в контексте конкретного пользователя и чтением системного реестра. Заголовочный файл лишь объявляет, что функция существует, но компоновщик должен получить корректную библиотеку импорта, указывающую, где находятся реализации этих функций.

Для устранения ошибок компоновщика была добавлена библиотека advapi32.lib. Это библиотека импорта Windows, которая предоставляет, среди прочего, функции, связанные с токенами безопасности, привилегиями, учётными записями пользователей и системным реестром. После её добавления на этап компоновки компоновщик смог разрешить ранее неразрешённые внешние символы и создать исполняемый файл.

cl /EHsc /DUNICODE /D_UNICODE RoguePlanet.cpp /Fe:rogue.exe /link advapi32.lib

Рисунок 9. Результат исправленной команды компиляции.

Рисунок 10. Результат успешного выполнения команды.

Рисунок 11. Созданный файл rogue.exe в рабочем каталоге ~\Downloads\\

Реакция Microsoft Defender и результат выполнения

Во время валидации созданный исполняемый файл был немедленно обнаружен Microsoft Defender как Trojan:Win64/RoguePlanet.DA!MTB с уровнем серьёзности «Серьёзный». Система предложила стандартные действия по защите, такие как перемещение файла в карантин или его удаление.

Рисунок 12. Сообщение Windows о том, что файл был заблокирован как вирус или потенциально нежелательное программное обеспечение.

Рисунок 13. Обнаружение Microsoft Defender: Trojan:Win64/RoguePlanet.DA!MTB.

Это означает, что механизмы обнаружения Defender идентифицировали подготовленный артефакт как вредоносный или потенциально опасный до того, как он мог быть успешно выполнен. С точки зрения защиты конечных точек это положительный результат, поскольку блокировка произошла на этапе исполняемого файла, а не только после наблюдения за последствиями выполнения программы.

После временного отключения защиты в реальном времени файл можно было выполнить. Наблюдения в ходе теста показывают, что после второго запуска удалось получить консоль, работающую с привилегиями SYSTEM. Этот результат подтверждает, что активная защита Defender имела важное значение для блокировки протестированного артефакта.

Рисунок 14. Выполнение программы в тестовой среде после отключения защиты в реальном времени.

Рисунок 15. Консоль, работающая в контексте системы в тестовой среде.

Оценка рисков

Обнаружение одного конкретного файла Microsoft Defender не означает, что риск уязвимости полностью устранён. Defender обнаружил известный или похожий артефакт PoC, в то время как модифицированная версия кода, другая компиляция, изменённая структура файла или другой загрузчик могут вести себя иначе в отношении сигнатурного или эвристического обнаружения. Результат теста следует рассматривать как подтверждение эффективности текущего уровня защиты против протестированного артефакта, а не как доказательство того, что каждый возможный вариант этой техники будет заблокирован.

В то же время результат теста показывает, что при активной защите в реальном времени и актуальных сигнатурах Defender успешно заблокировал созданный артефакт. Риск практической эксплуатации значительно возрастает, когда пользователь может отключить защиту в реальном времени, добавить исключение, разрешить обнаруженную угрозу или локально изменить конфигурацию защиты.

На практике это означает, что эффективное смягчение последствий не должно полагаться исключительно на наличие самого Defender, но также на централизованное принудительное применение его конфигурации и блокировку локальных изменений, вносимых пользователями.

9. Рекомендации

Централизованное принудительное применение конфигурации Microsoft Defender с помощью политик безопасности имеет решающее значение. Локальные пользователи не должны иметь возможности отключать защиту в реальном времени, добавлять исключения, разрешать обнаруженные угрозы или изменять параметры защиты. В такой модели пользователь не должен иметь возможности самостоятельно обойти обнаружение, выбрав такой параметр, как «Разрешить на устройстве», или временно отключив защиту.

• Централизованно применять защиту в реальном времени, облачную защиту и автоматическую отправку образцов;

• Запретить пользователям управление исключениями и действиями для обнаружений;

• Отслеживать события Defender, связанные с обнаружениями, карантином, попытками разрешить угрозы и изменениями конфигурации защиты;

• Рассматривать обнаружение Trojan:Win64/RoguePlanet.DA!MTB как событие безопасности, требующее анализа;

• Рассмотреть дополнительные механизмы, ограничивающие выполнение несанкционированных исполняемых файлов, такие как разрешение запуска приложений по белому списку, WDAC или AppLocker, в соответствии с возможностями среды.

Итоговые выводы

Тест подтвердил, что подготовка артефакта требовала среды, совместимой с нативным набором инструментов Microsoft. Попытка компиляции с использованием MinGW/G++ выявила проблемы совместимости с заголовками и структурами NT API, в то время как переход на MSVC и Windows SDK позволил довести процесс до этапа компоновки и в конечном итоге создать исполняемый файл после добавления корректной библиотеки импорта.

Microsoft Defender, работающий в обычном режиме с актуальными сигнатурами и включённой защитой в реальном времени, обнаружил созданный файл как Trojan:Win64/RoguePlanet.DA!MTB и заблокировал его выполнение. Это положительный результат теста с точки зрения защиты конечных точек.

В то же время отключение защиты в реальном времени позволило выполнить артефакт и привело к получению консоли с привилегиями SYSTEM. Практический вывод очевиден: конфигурация Defender должна принудительно применяться централизованно, а пользователи не должны иметь возможности локально ослаблять защиту, добавлять исключения или разрешать обнаруженные угрозы.