Rapport de validation du PoC RoguePlanet pour Microsoft Defender

Objectif et portée du rapport

Ce rapport concerne la validation du PoC RoguePlanet décrit publiquement et lié à Microsoft Defender. La technique décrite a été présentée dans les médias le 10 juin 2026 comme une élévation de privilèges locale (LPE) permettant à un utilisateur local d'obtenir les privilèges NT AUTHORITY\SYSTEM. Les descriptions publiques indiquent que le mécanisme utilise des fonctions employées par Microsoft Defender lors du traitement ou de l'analyse d'un fichier.

L'objectif du test était de déterminer si l'exploit pouvait être préparé et exécuté dans un environnement de laboratoire contrôlé, et d'observer comment les mécanismes de protection de Microsoft Defender se comportent sur un système Windows 11 à jour. Le rapport couvre l'environnement de test, l'état des mises à jour, la configuration de Microsoft Defender, la préparation de l'environnement de compilation, le résultat de la compilation, la réponse de Defender et les recommandations de réduction des risques.

Le test avait une finalité de recherche et a été réalisé localement sur un poste de travail de test dédié. Les résultats doivent être interprétés comme une évaluation du comportement d'un artefact spécifique et d'une configuration d'environnement spécifique, et non comme une confirmation complète de la résistance à toutes les variantes possibles de cette technique.

Sources référencées dans le matériel analysé :

• Article :

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

• Dépôt public du PoC :

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

• Source de l'installateur MSYS2 :

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

• Source de Visual Studio :

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

Environnement de test

Le PoC a été exécuté sur un poste de travail client fonctionnant en dehors d'un domaine Active Directory, dans le groupe de travail WORKGROUP. Le système d'exploitation installé sur le poste de travail était Microsoft Windows 11 Famille, version 25H2, architecture 64 bits.

Le jour de l'exécution du PoC, le système disposait des mises à jour de sécurité de juin 2026, ainsi que des mises à jour antérieures de mai et avril 2026. Cela signifie que le test a été effectué sur un système Windows 11 25H2 à jour, build 26200, après installation des derniers correctifs de sécurité disponibles à la date du test.

Configuration de Microsoft Defender

Microsoft Defender Antivirus était actif sur le poste de travail utilisé pour le test et fonctionnait en mode normal. Le service de protection était en cours d'exécution et activé, et la protection antivirus, la protection anti-logiciels espions, la surveillance du comportement et la protection en temps réel étaient actives.

Le jour du test, les signatures de Microsoft Defender étaient à jour. Les signatures antivirus, anti-logiciels espions et NIS avaient été mises à jour le 10.06.2026 à 13:27:32.

La dernière analyse rapide a été effectuée le 08.06.2026 entre 15:00:36 et 15:01:58, en utilisant la version des signatures 1.451.323.0. Une analyse complète n'avait pas été effectuée auparavant ou son historique n'était pas disponible, comme l'indique la valeur FullScanAge de 4294967295 et l'absence d'heures de début et de fin d'analyse complète.

Préparation de l'environnement de compilation

La première tentative de compilation du code depuis le dépôt GitHub s'est terminée par une erreur due à l'absence de l'en-tête winternl.h. Le message indiquait que le système ne disposait pas de l'ensemble complet des en-têtes Windows SDK requis par le code analysé.

Figure 1. Erreur d'en-tête winternl.h manquant lors de la première tentative de compilation.

Le code référençait également d'autres en-têtes liés à l'API Windows et à l'API NT, notamment windows.h, Psapi.h, ntstatus.h, virtdisk.h, shlwapi.h, taskschd.h et bcrypt.h. Pour cette raison, il a été nécessaire de préparer un environnement de compilation plus complet et d'installer les composants SDK appropriés.

Figure 2. Fragment de la liste des en-têtes requis par le code analysé.

Tentative d'utilisation de MSYS2/MinGW-w64

Dans un premier temps, MSYS2/MinGW-w64 a été utilisé pour préparer l'environnement de compilation. Cet environnement fournit des outils GNU pour Windows, dont les compilateurs gcc et g++. Les paquets dans MSYS2 sont gérés via pacman, qui joue un rôle similaire à apt sur les systèmes Linux ou winget sur Windows.

Figure 3. Fin de l'installation de MSYS2.

En utilisant pacman, la chaîne d'outils MinGW-w64 GCC/G++ a été installée, c'est-à-dire un ensemble d'outils permettant la compilation de code C/C++ pour Windows. Le paquet inclut, entre autres composants, le compilateur gcc, le compilateur C++ g++, l'éditeur de liens, ainsi que les en-têtes et bibliothèques nécessaires à la construction d'applications fonctionnant dans l'environnement Windows. Le but de cette tentative était de vérifier si le code pouvait être compilé en utilisant la chaîne d'outils ouverte disponible dans MSYS2, sans utiliser Visual Studio.

Figure 4. Installation des paquets MSYS2/MinGW-w64 via pacman.

Après l'installation, une tentative de compilation du code avec g++ a été effectuée. La commande spécifiait directement le chemin vers le fichier source et le chemin vers le fichier exécutable résultant.

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

Problème de mode Unicode

Le premier signe significatif d'un problème de mode Unicode était les messages du compilateur concernant des types de caractères incompatibles. Les journaux contenaient des erreurs indiquant que des valeurs de type const wchar_t* ou wchar_t* ne pouvaient pas être converties en LPCSTR ou LPSTR. Cela signifiait que le code passait des chaînes larges aux fonctions de l'API Windows, tandis que le compilateur sélectionnait les variantes de fonctions destinées aux chaînes ANSI classiques.

Dans l'API Windows, de nombreuses fonctions existent en deux variantes : ANSI, marquée du suffixe A, et Unicode, marquée du suffixe W. Par exemple, CreateFile peut être mappée en CreateFileA ou CreateFileW, et RegOpenKeyEx en RegOpenKeyExA ou RegOpenKeyExW. La variante A attend des paramètres de type char* ou LPCSTR, tandis que la variante W attend des paramètres de type wchar_t* ou LPCWSTR.

Dans le cas analysé, le code utilisait des littéraux sous la forme L"..." et des tampons de type wchar_t. En même temps, les messages d'erreur indiquaient que le compilateur sélectionnait des fonctions telles que GetModuleHandleA, RegOpenKeyExA, RegQueryValueExA, GetWindowsDirectoryA, CreateFileA et wsprintfA. C'était une indication directe que le code avait été écrit en mode Unicode, mais que la commande de compilation ne définissait pas UNICODE et _UNICODE.

Le mode Unicode a donc été forcé en ajoutant les définitions UNICODE et _UNICODE. Après ce changement, les fonctions de l'API Windows sans suffixe explicite devaient être mappées vers les variantes suffixées par W, telles que CreateFileW, RegOpenKeyExW, GetModuleHandleW et GetWindowsDirectoryW. Le fait que certaines des erreurs aient disparu après ce changement a confirmé le diagnostic.

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

Cependant, après la résolution des problèmes liés à Unicode, des erreurs subsistaient, indiquant une incompatibilité plus profonde entre le code et MinGW. Elles concernaient notamment des définitions en double des structures FILE_BASIC_INFORMATION et FILE_RENAME_INFORMATION, qui étaient définies à la fois dans le code source et dans les en-têtes MinGW. De plus, la version de FILE_RENAME_INFORMATION disponible dans MinGW différait de celle attendue par le code, notamment par l'absence du champ Flags.

Des erreurs supplémentaires résultaient également de l'approche plus restrictive du compilateur g++ concernant les types, en particulier pour les indicateurs d'énumération et les pointeurs de fonction. Cela concernait entre autres les types VIRTUAL_DISK_ACCESS_MASK et ATTACH_VIRTUAL_DISK_FLAG, ainsi que le passage de pointeurs de fonction en tant que void*. En conséquence, MinGW a été jugé inadapté à la compilation de ce code sans modifications importantes du code source.

Migration vers MSVC et Windows SDK

En raison des problèmes de compatibilité avec MinGW, un environnement MSVC et Windows SDK a été préparé. La charge de travail « Développement Desktop en C++ » a été sélectionnée dans l'installateur Visual Studio, car le code analysé était une application Windows native écrite en C/C++ utilisant directement l'API Windows et les composants du Windows SDK. Il ne s'agissait pas d'un projet .NET, Python, Node.js ou d'application web, donc les composants liés à ces technologies n'ont pas été installés.

Figure 5. Charge de travail Visual Studio et composants sélectionnés pour les applications de bureau C++.

Le composant le plus important était MSVC v143, le compilateur Microsoft C/C++ destiné à la création d'applications C/C++ pour Windows. Il a été sélectionné car la tentative précédente de compilation avec MinGW/G++ avait provoqué des erreurs de compatibilité liées aux en-têtes, aux types et aux structures de l'API NT. Le code utilisait des mécanismes spécifiques à Windows, donc l'environnement le plus compatible était le compilateur Microsoft accompagné des bibliothèques fournies par le Windows SDK.

Le SDK Windows 11 a également été installé. Ce composant contient les en-têtes et bibliothèques nécessaires pour utiliser les fonctions système de Windows, notamment windows.h, winternl.h, winreg.h, processthreadsapi.h, virtdisk.h, ainsi que les bibliothèques d'importation .lib utilisées lors de l'édition de liens. De plus, les outils CMake C++ ont été conservés comme composant auxiliaire, utile pour analyser des projets plus complexes.

Après l'installation, l'invite de commande x64 Native Tools pour VS Insiders a été utilisée — une interface en ligne de commande avec les chemins corrects définis pour le compilateur cl.exe, le SDK Windows et les bibliothèques de l'éditeur de liens.

Figure 6. Lancement de l'invite de commande x64 Native Tools pour VS Insiders.

Compilation avec MSVC

Après le passage à MSVC, le code a progressé beaucoup plus loin dans le processus de construction. La première commande renvoyait encore des erreurs liées au mappage des fonctions de l'API Windows vers les variantes ANSI, il a donc été nécessaire d'ajouter les définitions UNICODE et _UNICODE également lors de la compilation avec MSVC.

cl /EHsc RoguePlanet.cpp -o rogue.exe

Figure 7. Tentative de compilation avec MSVC sans configuration complète d'Unicode et de l'édition de liens.

Après l'ajout des options Unicode, le code a été traité plus avant, et les erreurs de compatibilité d'en-têtes et de types ont été remplacées par des erreurs d'édition de liens LNK2019. Cela signifiait que le compilateur avait déjà pu créer un fichier objet, tandis que l'éditeur de liens n'avait pas encore reçu toutes les bibliothèques d'importation requises par les fonctions de l'API Windows utilisées.

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

Figure 8. Erreurs d'édition de liens LNK2019 pour les fonctions de l'API Windows.

Les erreurs d'édition de liens concernaient des fonctions telles que CreateProcessAsUserW, OpenProcessToken, AdjustTokenPrivileges, DuplicateTokenEx, GetTokenInformation, LookupPrivilegeValueW, RegOpenKeyExW et RegQueryValueExW. Ces fonctions sont liées aux jetons de sécurité, aux privilèges, au démarrage de processus dans un contexte utilisateur spécifique et à la lecture du registre système. L'en-tête déclare seulement que la fonction existe, mais l'éditeur de liens doit recevoir la bibliothèque d'importation correcte indiquant où se trouvent les implémentations de ces fonctions.

Pour résoudre les erreurs de l'éditeur de liens, la bibliothèque advapi32.lib a été ajoutée. Il s'agit d'une bibliothèque d'importation Windows qui fournit, entre autres, des fonctions liées aux jetons de sécurité, aux privilèges, aux comptes utilisateur et au registre système. Après l'avoir ajoutée à l'étape d'édition de liens, l'éditeur de liens a pu résoudre les symboles externes précédemment non résolus et créer le fichier exécutable.

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

Figure 9. Résultat de la commande de compilation corrigée.

Figure 10. Résultat de la commande réussie.

Figure 11. Fichier rogue.exe créé dans le répertoire de travail ~\Downloads\\

Réponse de Microsoft Defender et résultat de l'exécution

Lors de la validation, le fichier exécutable créé a été immédiatement détecté par Microsoft Defender comme Trojan:Win64/RoguePlanet.DA!MTB avec le niveau de gravité « Sévère ». Le système a proposé des actions de protection standard, telles que le déplacement du fichier en quarantaine ou sa suppression.

Figure 12. Message Windows informant que le fichier a été bloqué comme virus ou logiciel potentiellement indésirable.

Figure 13. Détection par Microsoft Defender : Trojan:Win64/RoguePlanet.DA!MTB.

Cela signifie que les mécanismes de détection de Defender ont identifié l'artefact préparé comme malveillant ou potentiellement dangereux avant qu'il puisse être exécuté avec succès. Du point de vue de la protection des points de terminaison, il s'agit d'un résultat positif, car le blocage s'est produit au stade du fichier exécutable plutôt qu'après avoir observé les effets de l'exécution du programme.

Après avoir temporairement désactivé la protection en temps réel, le fichier a pu être exécuté. L'observation du test indique qu'après la deuxième exécution, il a été possible d'obtenir une console s'exécutant avec les privilèges SYSTEM. Ce résultat confirme que la protection active de Defender était importante pour bloquer l'artefact testé.

Figure 14. Exécution du programme dans l'environnement de test après désactivation de la protection en temps réel.

Figure 15. Console s'exécutant dans le contexte système dans l'environnement de test.

Évaluation des risques

La détection d'un fichier spécifique par Microsoft Defender ne signifie pas que le risque de vulnérabilité a été complètement éliminé. Defender a détecté un artefact PoC connu ou similaire, tandis qu'une version modifiée du code, une compilation différente, une structure de fichier modifiée ou un autre chargeur pourrait se comporter différemment vis-à-vis de la détection basée sur les signatures ou heuristique. Le résultat du test doit être traité comme une confirmation de l'efficacité de la couche de protection actuelle contre l'artefact testé, et non comme une preuve que chaque variation possible de la technique sera bloquée.

En même temps, le résultat du test indique qu'avec une protection en temps réel active et des signatures à jour, Defender a réussi à bloquer l'artefact créé. Le risque d'exploitation pratique augmente considérablement lorsqu'un utilisateur est capable de désactiver la protection en temps réel, d'ajouter une exclusion, d'autoriser une menace détectée ou de modifier localement la configuration de la protection.

En pratique, cela signifie qu'une atténuation efficace ne devrait pas reposer uniquement sur la présence de Defender lui-même, mais aussi sur un renforcement centralisé de sa configuration et le blocage des modifications locales effectuées par les utilisateurs.

Recommandations

Le renforcement centralisé de la configuration de Microsoft Defender via des politiques de sécurité est essentiel. Les utilisateurs locaux ne doivent pas être en mesure de désactiver la protection en temps réel, d'ajouter des exclusions, d'autoriser des menaces détectées ou de modifier les paramètres de protection. Dans un tel modèle, l'utilisateur ne doit pas pouvoir contourner indépendamment la détection en sélectionnant une option telle que « Autoriser sur l'appareil » ou en désactivant temporairement la protection.

• Renforcer de manière centralisée la protection en temps réel, la protection fournie par le cloud et l'envoi automatique d'échantillons ;
• Bloquer les utilisateurs dans la gestion des exclusions et des actions pour les détections ;
• Surveiller les événements Defender liés aux détections, à la quarantaine, aux tentatives d'autorisation de menaces et aux modifications de la configuration de protection ;
• Traiter la détection Trojan:Win64/RoguePlanet.DA!MTB comme un événement de sécurité nécessitant une analyse ;
• Envisager des mécanismes supplémentaires limitant l'exécution de fichiers exécutables non autorisés, tels que la liste blanche d'applications, WDAC ou AppLocker, selon les capacités de l'environnement.

Conclusions finales

Le test a confirmé que la préparation de l'artefact nécessitait un environnement compatible avec la chaîne d'outils native de Microsoft. La tentative de compilation avec MinGW/G++ a révélé des problèmes de compatibilité avec les en-têtes et structures de l'API NT, tandis que le passage à MSVC et Windows SDK a permis au processus d'atteindre l'étape d'édition de liens et finalement de créer le fichier exécutable après ajout de la bibliothèque d'importation correcte.

Microsoft Defender fonctionnant en mode normal, avec des signatures à jour et la protection en temps réel activée, a détecté le fichier créé comme Trojan:Win64/RoguePlanet.DA!MTB et a bloqué son exécution. Il s'agit d'un résultat de test positif du point de vue de la protection des points de terminaison.

En même temps, la désactivation de la protection en temps réel a permis l'exécution de l'artefact et a conduit à l'obtention d'une console avec les privilèges SYSTEM. La conclusion pratique est claire : la configuration de Defender doit être renforcée de manière centralisée, et les utilisateurs ne doivent pas être en mesure d'affaiblir localement la protection, d'ajouter des exclusions ou d'autoriser des menaces détectées.