Relatório de Validação do PoC RoguePlanet para o Microsoft Defender

Objetivo e escopo do relatório

Este relatório trata da validação do PoC RoguePlanet descrito publicamente relacionado ao Microsoft Defender. A técnica descrita foi apresentada na mídia em 10 de junho de 2026 como uma Escalação Local de Privilégio (LPE), na qual um usuário local pode obter privilégios de NT AUTHORITY\SYSTEM. As descrições públicas indicaram que o mecanismo utiliza funções usadas pelo Microsoft Defender ao manipular ou examinar um arquivo.

O objetivo do teste foi determinar se o exploit poderia ser preparado e executado em um ambiente de laboratório controlado e observar como os mecanismos de proteção do Microsoft Defender se comportam em um sistema Windows 11 atualizado. O relatório abrange o ambiente de teste, status de atualização, configuração do Microsoft Defender, preparação do ambiente de compilação, resultado da compilação, resposta do Defender e recomendações para redução de risco.

O teste foi orientado à pesquisa e realizado localmente em uma estação de trabalho dedicada. Os resultados devem ser interpretados como uma avaliação do comportamento de um artefato específico e de uma configuração de ambiente específica, não como confirmação total de resistência a todas as variantes possíveis desta técnica.

Fontes referenciadas no material analisado:

• Artigo:

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

• Repositório público do PoC:

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

• Fonte do instalador MSYS2:

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

• Fonte do Visual Studio:

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

Ambiente de teste

O PoC foi realizado em uma estação de trabalho cliente operando fora de um domínio Active Directory, no grupo de trabalho WORKGROUP. O sistema operacional instalado na estação de trabalho foi Microsoft Windows 11 Home, versão 25H2, arquitetura de 64 bits.

No dia em que o PoC foi realizado, o sistema tinha as atualizações de segurança de junho de 2026 instaladas, bem como atualizações anteriores de maio e abril de 2026. Isso significa que o teste foi realizado em um sistema Windows 11 25H2 atualizado, compilação 26200, após a instalação dos patches de segurança mais recentes disponíveis na data do teste.

Configuração do Microsoft Defender

O Microsoft Defender Antivírus estava ativo na estação de trabalho usada para o teste e estava sendo executado em modo normal. O serviço de proteção estava em execução e ativado, e a proteção antivírus, antispyware, monitoramento de comportamento e proteção em tempo real estavam ativos.

No dia do teste, as assinaturas do Microsoft Defender estavam atualizadas. As assinaturas de antivírus, antispyware e NIS foram atualizadas em 10.06.2026 às 13:27:32.

A última verificação rápida foi realizada em 08.06.2026 entre 15:00:36 e 15:01:58, usando a versão de assinaturas 1.451.323.0. Uma verificação completa não havia sido realizada anteriormente ou seu histórico não estava disponível, conforme indicado pelo valor FullScanAge de 4294967295 e pela ausência de horários de início e término da verificação completa.

Preparação do ambiente de compilação

A primeira tentativa de compilar o código do repositório GitHub terminou com um erro causado pela falta do cabeçalho winternl.h. A mensagem indicava que o sistema não possuía o conjunto completo de cabeçalhos do Windows SDK exigidos pelo código analisado.

Figura 1. Erro de cabeçalho winternl.h ausente durante a primeira tentativa de compilação.

O código também referenciava outros cabeçalhos relacionados à API do Windows e à API NT, incluindo windows.h, Psapi.h, ntstatus.h, virtdisk.h, shlwapi.h, taskschd.h e bcrypt.h. Por esse motivo, foi necessário preparar um ambiente de compilação mais completo e instalar os componentes apropriados do SDK.

Figura 2. Trecho da lista de cabeçalhos exigidos pelo código analisado.

Tentativa de usar MSYS2/MinGW-w64

Inicialmente, MSYS2/MinGW-w64 foi usado para preparar o ambiente de compilação. Esse ambiente fornece ferramentas GNU para Windows, incluindo os compiladores gcc e g++. Os pacotes no MSYS2 são gerenciados usando pacman, que desempenha uma função semelhante ao apt em sistemas Linux ou winget no Windows.

Figura 3. Conclusão da instalação do MSYS2.

Usando pacman, a toolchain GCC/G++ do MinGW-w64 foi instalada, ou seja, um conjunto de ferramentas que permite a compilação de código C/C++ para Windows. O pacote inclui, entre outros componentes, o compilador gcc, o compilador C++ g++, o linker e os cabeçalhos e bibliotecas necessários para construir aplicativos executados no ambiente Windows. O objetivo dessa tentativa foi verificar se o código poderia ser compilado usando a toolchain aberta disponível no MSYS2, sem usar o Visual Studio.

Figura 4. Instalação de pacotes MSYS2/MinGW-w64 usando pacman.

Após a instalação, foi feita uma tentativa de compilar o código usando g++. O comando especificou diretamente o caminho para o arquivo de origem e o caminho para o arquivo executável resultante.

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

Problema de modo Unicode

O primeiro indicativo significativo de um problema de modo Unicode foram as mensagens do compilador sobre tipos de caracteres incompatíveis. Os logs continham erros informando que valores do tipo const wchar_t* ou wchar_t* não podiam ser convertidos para LPCSTR ou LPSTR. Isso significava que o código estava passando strings de caracteres largos para funções da API do Windows, enquanto o compilador selecionava variantes de função destinadas a strings ANSI clássicas.

Na API do Windows, muitas funções existem em duas variantes: ANSI, marcadas com o sufixo A, e Unicode, marcadas com o sufixo W. Por exemplo, CreateFile pode ser mapeada como CreateFileA ou CreateFileW, e RegOpenKeyEx como RegOpenKeyExA ou RegOpenKeyExW. A variante A espera parâmetros do tipo char* ou LPCSTR, enquanto a variante W espera parâmetros do tipo wchar_t* ou LPCWSTR.

No caso analisado, o código usava literais na forma L"..." e buffers do tipo wchar_t. Ao mesmo tempo, as mensagens de erro indicavam que o compilador selecionava funções como GetModuleHandleA, RegOpenKeyExA, RegQueryValueExA, GetWindowsDirectoryA, CreateFileA e wsprintfA. Isso era uma indicação direta de que o código havia sido escrito pensando no modo Unicode, mas o comando de compilação não definia UNICODE e _UNICODE.

O modo Unicode foi, portanto, forçado adicionando as definições UNICODE e _UNICODE. Após essa alteração, as funções da API do Windows sem sufixo explícito devem ser mapeadas para variantes com sufixo W, como CreateFileW, RegOpenKeyExW, GetModuleHandleW e GetWindowsDirectoryW. O fato de alguns dos erros terem desaparecido após essa alteração confirmou a correção do diagnóstico.

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

Após a remoção dos problemas relacionados ao Unicode, no entanto, permaneceram erros que indicavam uma incompatibilidade mais profunda entre o código e o MinGW. Eles diziam respeito, entre outros, a definições duplicadas das estruturas FILE_BASIC_INFORMATION e FILE_RENAME_INFORMATION, que estavam definidas tanto no código-fonte quanto nos cabeçalhos do MinGW. Além disso, a versão de FILE_RENAME_INFORMATION disponível no MinGW diferia da esperada pelo código, incluindo a ausência do campo Flags.

Erros adicionais também resultaram da abordagem mais restritiva do compilador g++ em relação a tipos, especialmente com flags de enumeração e ponteiros de função. Isso dizia respeito, entre outros, aos tipos VIRTUAL_DISK_ACCESS_MASK e ATTACH_VIRTUAL_DISK_FLAG, bem como à passagem de ponteiros de função como void*. Como resultado, o MinGW foi considerado inadequado para compilar este código sem modificações significativas no código-fonte.

5. Migração para MSVC e Windows SDK

Devido a problemas de compatibilidade com o MinGW, foi preparado um ambiente MSVC e Windows SDK. A carga de trabalho “Desenvolvimento para desktop com C++” foi selecionada no instalador do Visual Studio porque o código analisado era um aplicativo nativo do Windows escrito em C/C++ e usava diretamente a API do Windows e componentes do Windows SDK. Não era um projeto .NET, Python, Node.js ou aplicativo web, portanto, componentes relacionados a essas tecnologias não foram instalados.

Figura 5. Carga de trabalho e componentes do Visual Studio selecionados para aplicativos C++ de desktop.

O componente mais importante era o MSVC v143, o compilador Microsoft C/C++ destinado à compilação de aplicativos C/C++ para Windows. Ele foi selecionado porque a tentativa anterior de compilar com MinGW/G++ causou erros de compatibilidade relacionados a cabeçalhos, tipos e estruturas da API NT. O código usava mecanismos específicos do Windows, portanto, o ambiente mais compatível era o compilador da Microsoft junto com as bibliotecas fornecidas pelo Windows SDK.

O Windows 11 SDK também foi instalado. Este componente contém os cabeçalhos e bibliotecas necessários para usar funções do sistema Windows, incluindo windows.h, winternl.h, winreg.h, processthreadsapi.h, virtdisk.h e bibliotecas de importação .lib usadas durante a vinculação. Além disso, as ferramentas CMake para C++ foram mantidas como um componente auxiliar, útil ao analisar projetos mais complexos.

Após a instalação, o Prompt de Comando x64 Native Tools para VS Insiders foi usado — uma CLI com os caminhos corretos definidos para o compilador cl.exe, Windows SDK e bibliotecas do linker.

Figura 6. Inicialização do Prompt de Comando x64 Native Tools para VS Insiders.

6. Compilação usando MSVC

Após a mudança para o MSVC, o código progrediu significativamente no processo de compilação. O primeiro comando ainda retornou erros relacionados ao mapeamento de funções da API do Windows para variantes ANSI, então foi necessário adicionar as definições UNICODE e _UNICODE também durante a compilação com MSVC.

cl /EHsc RoguePlanet.cpp -o rogue.exe

Figura 7. Tentativa de compilação usando MSVC sem configuração completa de Unicode e vinculação.

Após adicionar as opções Unicode, o código foi processado mais adiante, e os erros de compatibilidade de cabeçalho e tipo foram substituídos por erros de vinculação LNK2019. Isso significava que o compilador já era capaz de criar um arquivo objeto, enquanto o linker ainda não havia recebido todas as bibliotecas de importação exigidas pelas funções da API do Windows usadas.

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

Figura 8. Erros de vinculação LNK2019 para funções da API do Windows.

Os erros do linker envolviam funções como CreateProcessAsUserW, OpenProcessToken, AdjustTokenPrivileges, DuplicateTokenEx, GetTokenInformation, LookupPrivilegeValueW, RegOpenKeyExW e RegQueryValueExW. Essas funções estão relacionadas a tokens de segurança, privilégios, inicialização de processos em um contexto de usuário específico e leitura do registro do sistema. O cabeçalho apenas declara que a função existe, mas o linker deve receber a biblioteca de importação correta indicando onde as implementações dessas funções estão localizadas.

Para resolver os erros do linker, a biblioteca advapi32.lib foi adicionada. Esta é uma biblioteca de importação do Windows que fornece, entre outras coisas, funções relacionadas a tokens de segurança, privilégios, contas de usuário e o registro do sistema. Após adicioná-la ao estágio de vinculação, o linker conseguiu resolver os símbolos externos anteriormente não resolvidos e criar o arquivo executável.

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

Figura 9. Resultado do comando de compilação corrigido.

Figura 10. Resultado do comando bem-sucedido.

Figura 11. Arquivo rogue.exe criado no diretório de trabalho ~\Downloads\\

Resposta do Microsoft Defender e resultado da execução

Durante a validação, o arquivo executável criado foi imediatamente detectado pelo Microsoft Defender como Trojan:Win64/RoguePlanet.DA!MTB com o nível de gravidade “Severo”. O sistema propôs ações de proteção padrão, como mover o arquivo para quarentena ou excluí-lo.

Figura 12. Mensagem do Windows informando que o arquivo foi bloqueado como vírus ou software potencialmente indesejado.

Figura 13. Detecção do Microsoft Defender: Trojan:Win64/RoguePlanet.DA!MTB.

Isso significa que os mecanismos de detecção do Defender identificaram o artefato preparado como malicioso ou potencialmente perigoso antes que pudesse ser executado com sucesso. Da perspectiva da proteção de endpoint, este é um resultado positivo, porque o bloqueio ocorreu no estágio do arquivo executável, e não apenas após observar os efeitos da execução do programa.

Após a proteção em tempo real ser temporariamente desativada, o arquivo pôde ser executado. A observação do teste indica que, após a segunda execução, foi possível obter um console em execução com privilégios SYSTEM. Esse resultado confirma que a proteção ativa do Defender foi importante para bloquear o artefato testado.

Figura 14. Execução do programa no ambiente de teste após a desativação da proteção em tempo real.

Figura 15. Console em execução no contexto do sistema no ambiente de teste.

Avaliação de risco

A detecção de um arquivo específico pelo Microsoft Defender não significa que o risco da vulnerabilidade foi totalmente eliminado. O Defender detectou um artefato PoC conhecido ou semelhante, enquanto uma versão modificada do código, uma compilação diferente, uma estrutura de arquivo alterada ou outro loader poderia se comportar de maneira diferente em relação à detecção baseada em assinatura ou heurística. O resultado do teste deve ser tratado como confirmação da eficácia da camada de proteção atual contra o artefato testado, não como prova de que todas as variações possíveis da técnica serão bloqueadas.

Ao mesmo tempo, o resultado do teste indica que, com proteção em tempo real ativa e assinaturas atualizadas, o Defender bloqueou com sucesso o artefato criado. O risco de exploração prática aumenta significativamente quando um usuário consegue desativar a proteção em tempo real, adicionar uma exclusão, permitir uma ameaça detectada ou modificar localmente a configuração de proteção.

Na prática, isso significa que a mitigação eficaz não deve depender apenas da presença do Defender em si, mas também da imposição centralizada de sua configuração e do bloqueio de alterações locais feitas pelos usuários.

9. Recomendações

A imposição centralizada da configuração do Microsoft Defender por meio de políticas de segurança é fundamental. Os usuários locais não devem ser capazes de desativar a proteção em tempo real, adicionar exclusões, permitir ameaças detectadas ou modificar as configurações de proteção. Nesse modelo, o usuário não deve ser capaz de contornar a detecção de forma independente selecionando uma opção como “Permitir no dispositivo” ou desativando temporariamente a proteção.

• Impor centralmente a proteção em tempo real, a proteção entregue pela nuvem e o envio automático de amostras;

• Bloquear os usuários de gerenciar exclusões e ações para detecções;

• Monitorar eventos do Defender relacionados a detecções, quarentena, tentativas de permitir ameaças e alterações na configuração de proteção;

• Tratar a detecção Trojan:Win64/RoguePlanet.DA!MTB como um evento de segurança que requer análise;

• Considerar mecanismos adicionais que limitem a execução de arquivos executáveis não autorizados, como lista de permissões de aplicativos, WDAC ou AppLocker, de acordo com as capacidades do ambiente.

Conclusões finais

O teste confirmou que a preparação do artefato exigia um ambiente compatível com a toolchain nativa da Microsoft. A tentativa de compilação usando MinGW/G++ revelou problemas de compatibilidade com cabeçalhos e estruturas da API NT, enquanto a mudança para MSVC e Windows SDK permitiu que o processo chegasse ao estágio de vinculação e, finalmente, criasse o arquivo executável após adicionar a biblioteca de importação correta.

O Microsoft Defender executando em modo normal, com assinaturas atualizadas e proteção em tempo real ativada, detectou o arquivo criado como Trojan:Win64/RoguePlanet.DA!MTB e bloqueou sua execução. Este é um resultado positivo do teste da perspectiva da proteção de endpoint.

Ao mesmo tempo, a desativação da proteção em tempo real permitiu a execução do artefato e levou à obtenção de um console com privilégios SYSTEM. A conclusão prática é clara: a configuração do Defender deve ser imposta centralmente, e os usuários não devem ser capazes de enfraquecer localmente a proteção, adicionar exclusões ou permitir ameaças detectadas.