Informe de validación del PoC RoguePlanet para Microsoft Defender

Propósito y alcance del informe

Este informe trata sobre la validación del PoC RoguePlanet descrito públicamente y relacionado con Microsoft Defender. La técnica descrita se presentó en los medios el 10 de junio de 2026 como una Escalada de Privilegios Local (LPE), mediante la cual un usuario local puede obtener privilegios de NT AUTHORITY\SYSTEM. Las descripciones públicas indicaban que el mecanismo utiliza funciones empleadas por Microsoft Defender al manejar o escanear un archivo.

El propósito de la prueba era determinar si el exploit podía prepararse y ejecutarse en un entorno de laboratorio controlado, y observar cómo se comportan los mecanismos de protección de Microsoft Defender en un sistema Windows 11 actualizado. El informe cubre el entorno de prueba, el estado de las actualizaciones, la configuración de Microsoft Defender, la preparación del entorno de compilación, el resultado de la compilación, la respuesta de Defender y las recomendaciones para la reducción de riesgos.

La prueba tenía un enfoque de investigación y se realizó localmente en una estación de trabajo de prueba dedicada. Los resultados deben interpretarse como una evaluación del comportamiento de un artefacto específico y de una configuración de entorno específica, no como una confirmación completa de resistencia a todas las variantes posibles de esta técnica.

Fuentes referenciadas en el material analizado:

• Artículo:

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

• Repositorio público del PoC:

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

• Origen del instalador de MSYS2:

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

• Origen de Visual Studio:

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

Entorno de prueba

El PoC se realizó en una estación de trabajo cliente que opera fuera de un dominio de Active Directory, en el grupo de trabajo WORKGROUP. El sistema operativo instalado en la estación de trabajo era Microsoft Windows 11 Home, versión 25H2, arquitectura de 64 bits.

El día en que se realizó el PoC, el sistema tenía instaladas las actualizaciones de seguridad de junio de 2026, así como actualizaciones anteriores de mayo y abril de 2026. Esto significa que la prueba se llevó a cabo en un sistema Windows 11 25H2 actualizado, compilación 26200, después de la instalación de los parches de seguridad más recientes disponibles en la fecha de la prueba.

Configuración de Microsoft Defender

Microsoft Defender Antivirus estaba activo en la estación de trabajo utilizada para la prueba y se ejecutaba en modo normal. El servicio de protección estaba en ejecución y habilitado, y la protección antivirus, la protección contra software espía, la supervisión del comportamiento y la protección en tiempo real estaban activas.

El día de la prueba, las firmas de Microsoft Defender estaban actualizadas. Las firmas de antivirus, antispyware y NIS se habían actualizado el 10.06.2026 a las 13:27:32.

El último análisis rápido se realizó el 08.06.2026 entre las 15:00:36 y las 15:01:58, utilizando la versión de firmas 1.451.323.0. No se había realizado un análisis completo anteriormente o su historial no estaba disponible, como indica el valor FullScanAge de 4294967295 y la ausencia de horas de inicio y fin del análisis completo.

Preparación del entorno de compilación

El primer intento de compilar el código del repositorio de GitHub terminó con un error causado por la ausencia del encabezado winternl.h. El mensaje indicaba que el sistema no tenía el conjunto completo de encabezados del Windows SDK requeridos por el código analizado.

Figura 1. Error por encabezado winternl.h faltante durante el primer intento de compilación.

El código también hacía referencia a otros encabezados relacionados con la API de Windows y la API de NT, incluidos windows.h, Psapi.h, ntstatus.h, virtdisk.h, shlwapi.h, taskschd.h y bcrypt.h. Por esta razón, fue necesario preparar un entorno de compilación más completo e instalar los componentes adecuados del SDK.

Figura 2. Fragmento de la lista de encabezados requeridos por el código analizado.

Intento de uso de MSYS2/MinGW-w64

Inicialmente, se utilizó MSYS2/MinGW-w64 para preparar el entorno de compilación. Este entorno proporciona herramientas GNU para Windows, incluidos los compiladores gcc y g++. Los paquetes en MSYS2 se gestionan con pacman, que cumple un papel similar al de apt en sistemas Linux o winget en Windows.

Figura 3. Finalización de la instalación de MSYS2.

Usando pacman, se instaló la cadena de herramientas MinGW-w64 GCC/G++, es decir, un conjunto de herramientas que permite compilar código C/C++ para Windows. El paquete incluye, entre otros componentes, el compilador gcc, el compilador g++ de C++, el enlazador, y los encabezados y bibliotecas necesarios para crear aplicaciones que se ejecutan en el entorno Windows. El propósito de este intento era comprobar si el código podía compilarse utilizando la cadena de herramientas abierta disponible en MSYS2, sin usar Visual Studio.

Figura 4. Instalación de paquetes de MSYS2/MinGW-w64 usando pacman.

Después de la instalación, se intentó compilar el código con g++. El comando especificaba directamente la ruta al archivo fuente y la ruta al archivo ejecutable resultante.

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

Problema del modo Unicode

El primer indicio significativo de un problema de modo Unicode fueron los mensajes del compilador sobre tipos de caracteres incompatibles. Los registros contenían errores que indicaban que los valores de tipo const wchar_t* o wchar_t* no podían convertirse a LPCSTR o LPSTR. Esto significaba que el código estaba pasando cadenas de caracteres anchos a funciones de la API de Windows, mientras que el compilador seleccionaba variantes de funciones destinadas a cadenas ANSI clásicas.

En la API de Windows, muchas funciones existen en dos variantes: ANSI, marcada con el sufijo A, y Unicode, marcada con el sufijo W. Por ejemplo, CreateFile puede asignarse como CreateFileA o CreateFileW, y RegOpenKeyEx como RegOpenKeyExA o RegOpenKeyExW. La variante A espera parámetros de tipo char* o LPCSTR, mientras que la variante W espera parámetros de tipo wchar_t* o LPCWSTR.

En el caso analizado, el código utilizaba literales en la forma L"..." y búferes de tipo wchar_t. Al mismo tiempo, los mensajes de error indicaban que el compilador seleccionaba funciones como GetModuleHandleA, RegOpenKeyExA, RegQueryValueExA, GetWindowsDirectoryA, CreateFileA y wsprintfA. Esto era una indicación directa de que el código se había escrito pensando en el modo Unicode, pero el comando de compilación no definía UNICODE ni _UNICODE.

Por lo tanto, se forzó el modo Unicode añadiendo las definiciones UNICODE y _UNICODE. Tras este cambio, las funciones de la API de Windows sin sufijo explícito deberían asignarse a variantes con sufijo W, como CreateFileW, RegOpenKeyExW, GetModuleHandleW y GetWindowsDirectoryW. El hecho de que algunos errores desaparecieran tras este cambio confirmó la corrección del diagnóstico.

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

Sin embargo, tras eliminar los problemas relacionados con Unicode, permanecieron errores que indicaban una incompatibilidad más profunda entre el código y MinGW. Concernían, entre otras cosas, definiciones duplicadas de las estructuras FILE_BASIC_INFORMATION y FILE_RENAME_INFORMATION, que estaban definidas tanto en el código fuente como en los encabezados de MinGW. Además, la versión de FILE_RENAME_INFORMATION disponible en MinGW difería de la esperada por el código, incluida la ausencia del campo Flags.

Errores adicionales también se debieron al enfoque más restrictivo del compilador g++ respecto a los tipos, especialmente con los flags de enumeración y los punteros a función. Esto concernía, entre otros, a los tipos VIRTUAL_DISK_ACCESS_MASK y ATTACH_VIRTUAL_DISK_FLAG, así como al paso de punteros a función como void*. Como resultado, se consideró que MinGW no era adecuado para compilar este código sin modificaciones significativas del código fuente.

5. Migración a MSVC y Windows SDK

Debido a los problemas de compatibilidad con MinGW, se preparó un entorno con MSVC y Windows SDK. Se seleccionó la carga de trabajo "Desarrollo para escritorio con C++" en el instalador de Visual Studio porque el código analizado era una aplicación nativa de Windows escrita en C/C++ y usaba directamente componentes de la API de Windows y del Windows SDK. No era un proyecto .NET, Python, Node.js ni una aplicación web, por lo que no se instalaron componentes relacionados con esas tecnologías.

Figura 5. Carga de trabajo y componentes de Visual Studio seleccionados para aplicaciones C++ de escritorio.

El componente más importante era MSVC v143, el compilador de Microsoft C/C++ destinado a crear aplicaciones C/C++ para Windows. Se seleccionó porque el intento anterior de compilar con MinGW/G++ causó errores de compatibilidad relacionados con encabezados, tipos y estructuras de la API de NT. El código usaba mecanismos específicos de Windows, por lo que el entorno más compatible era el compilador de Microsoft junto con las bibliotecas proporcionadas por el Windows SDK.

También se instaló el Windows 11 SDK. Este componente contiene los encabezados y bibliotecas necesarios para usar las funciones del sistema Windows, incluidos windows.h, winternl.h, winreg.h, processthreadsapi.h, virtdisk.h y las bibliotecas de importación .lib utilizadas durante el enlace. Además, se conservaron las herramientas C++ CMake como componente auxiliar, útil al analizar proyectos más complejos.

Después de la instalación, se utilizó el símbolo del sistema x64 Native Tools para VS Insiders, una CLI con las rutas correctas establecidas para el compilador cl.exe, el Windows SDK y las bibliotecas del enlazador.

Figura 6. Inicio del símbolo del sistema x64 Native Tools para VS Insiders.

6. Compilación con MSVC

Tras cambiar a MSVC, el código avanzó significativamente más en el proceso de compilación. El primer comando aún devolvía errores relacionados con la asignación de funciones de la API de Windows a variantes ANSI, por lo que fue necesario añadir las definiciones UNICODE y _UNICODE también durante la compilación con MSVC.

cl /EHsc RoguePlanet.cpp -o rogue.exe

Figura 7. Intento de compilación con MSVC sin configuración completa de Unicode y enlace.

Después de añadir los modificadores Unicode, el código se procesó más allá, y los errores de compatibilidad de encabezados y tipos fueron reemplazados por errores de enlazador LNK2019. Esto significaba que el compilador ya podía crear un archivo objeto, mientras que el enlazador aún no había recibido todas las bibliotecas de importación requeridas por las funciones de la API de Windows utilizadas.

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

Figura 8. Errores de enlazador LNK2019 para funciones de la API de Windows.

Los errores del enlazador involucraban funciones como CreateProcessAsUserW, OpenProcessToken, AdjustTokenPrivileges, DuplicateTokenEx, GetTokenInformation, LookupPrivilegeValueW, RegOpenKeyExW y RegQueryValueExW. Estas funciones están relacionadas con tokens de seguridad, privilegios, inicio de procesos en un contexto de usuario específico y lectura del registro del sistema. El encabezado solo declara que la función existe, pero el enlazador debe recibir la biblioteca de importación correcta que indica dónde se encuentran las implementaciones de esas funciones.

Para resolver los errores del enlazador, se añadió la biblioteca advapi32.lib. Esta es una biblioteca de importación de Windows que proporciona, entre otras cosas, funciones relacionadas con tokens de seguridad, privilegios, cuentas de usuario y el registro del sistema. Después de añadirla a la etapa de enlace, el enlazador pudo resolver los símbolos externos previamente no resueltos y crear el archivo ejecutable.

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

Figura 9. Resultado del comando de compilación corregido.

Figura 10. Resultado del comando exitoso.

Figura 11. Archivo rogue.exe creado en el directorio de trabajo ~\Downloads\\

Respuesta de Microsoft Defender y resultado de la ejecución

Durante la validación, el archivo ejecutable creado fue detectado inmediatamente por Microsoft Defender como Trojan:Win64/RoguePlanet.DA!MTB con el nivel de gravedad "Grave". El sistema propuso acciones de protección estándar, como mover el archivo a cuarentena o eliminarlo.

Figura 12. Mensaje de Windows que informa que el archivo fue bloqueado como virus o software potencialmente no deseado.

Figura 13. Detección de Microsoft Defender: Trojan:Win64/RoguePlanet.DA!MTB.

Esto significa que los mecanismos de detección de Defender identificaron el artefacto preparado como malicioso o potencialmente peligroso antes de que pudiera ejecutarse con éxito. Desde la perspectiva de la protección de endpoints, este es un resultado positivo, porque el bloqueo ocurrió en la etapa del archivo ejecutable y no solo después de observar los efectos de la ejecución del programa.

Después de deshabilitar temporalmente la protección en tiempo real, el archivo pudo ejecutarse. La observación de la prueba indica que tras la segunda ejecución fue posible obtener una consola ejecutándose con privilegios de SYSTEM. Este resultado confirma que la protección activa de Defender fue importante para bloquear el artefacto probado.

Figura 14. Ejecución del programa en el entorno de prueba después de deshabilitar la protección en tiempo real.

Figura 15. Consola ejecutándose en el contexto del sistema en el entorno de prueba.

Evaluación de riesgos

La detección de un archivo específico por Microsoft Defender no significa que el riesgo de la vulnerabilidad se haya eliminado por completo. Defender detectó un artefacto PoC conocido o similar, mientras que una versión modificada del código, una compilación diferente, una estructura de archivo cambiada u otro cargador podrían comportarse de manera diferente respecto a la detección basada en firmas o heurística. El resultado de la prueba debe tratarse como una confirmación de la efectividad de la capa de protección actual contra el artefacto probado, no como prueba de que todas las variaciones posibles de la técnica serán bloqueadas.

Al mismo tiempo, el resultado de la prueba indica que con la protección en tiempo real activa y las firmas actualizadas, Defender bloqueó con éxito el artefacto creado. El riesgo de explotación práctica aumenta significativamente cuando un usuario puede deshabilitar la protección en tiempo real, añadir una exclusión, permitir una amenaza detectada o modificar localmente la configuración de protección.

En la práctica, esto significa que la mitigación efectiva no debe depender únicamente de la presencia de Defender en sí, sino también de imponer centralmente su configuración y bloquear los cambios locales realizados por los usuarios.

9. Recomendaciones

Es crítico imponer centralmente la configuración de Microsoft Defender mediante políticas de seguridad. Los usuarios locales no deberían poder deshabilitar la protección en tiempo real, añadir exclusiones, permitir amenazas detectadas ni modificar los ajustes de protección. En tal modelo, el usuario no debería poder eludir la detección de forma independiente seleccionando una opción como "Permitir en el dispositivo" o deshabilitando temporalmente la protección.

• Imponer centralmente la protección en tiempo real, la protección en la nube y el envío automático de muestras;

• Bloquear a los usuarios la gestión de exclusiones y acciones para detecciones;

• Supervisar los eventos de Defender relacionados con detecciones, cuarentena, intentos de permitir amenazas y cambios en la configuración de protección;

• Tratar la detección Trojan:Win64/RoguePlanet.DA!MTB como un evento de seguridad que requiere análisis;

• Considerar mecanismos adicionales que limiten la ejecución de archivos ejecutables no autorizados, como listas de permitidos de aplicaciones, WDAC o AppLocker, según las capacidades del entorno.

Conclusiones finales

La prueba confirmó que preparar el artefacto requería un entorno compatible con la cadena de herramientas nativa de Microsoft. El intento de compilación con MinGW/G++ reveló problemas de compatibilidad con los encabezados y estructuras de la API de NT, mientras que el cambio a MSVC y Windows SDK permitió que el proceso alcanzara la etapa de enlace y, finalmente, creara el archivo ejecutable después de añadir la biblioteca de importación correcta.

Microsoft Defender, ejecutándose en modo normal, con firmas actualizadas y protección en tiempo real habilitada, detectó el archivo creado como Trojan:Win64/RoguePlanet.DA!MTB y bloqueó su ejecución. Este es un resultado positivo de la prueba desde la perspectiva de la protección de endpoints.

Al mismo tiempo, deshabilitar la protección en tiempo real permitió ejecutar el artefacto y condujo a obtener una consola con privilegios de SYSTEM. La conclusión práctica es clara: la configuración de Defender debe imponerse centralmente, y los usuarios no deberían poder debilitar localmente la protección, añadir exclusiones ni permitir amenazas detectadas.