RoguePlanet PoC-Validierungsbericht für Microsoft Defender

Zweck und Umfang des Berichts

Dieser Bericht betrifft die Validierung des öffentlich beschriebenen RoguePlanet PoC im Zusammenhang mit Microsoft Defender. Die beschriebene Technik wurde am 10. Juni 2026 in den Medien als Local Privilege Escalation (LPE) vorgestellt, bei der ein lokaler Benutzer NT AUTHORITY\SYSTEM-Berechtigungen erlangen kann. Öffentliche Beschreibungen deuteten darauf hin, dass der Mechanismus Funktionen verwendet, die von Microsoft Defender beim Verarbeiten oder Scannen einer Datei genutzt werden.

Der Zweck des Tests bestand darin, festzustellen, ob der Exploit in einer kontrollierten Laborumgebung vorbereitet und ausgeführt werden kann, und zu beobachten, wie sich die Schutzmechanismen von Microsoft Defender auf einem aktuellen Windows 11-System verhalten. Der Bericht umfasst die Testumgebung, den Update-Status, die Microsoft Defender-Konfiguration, die Vorbereitung der Kompilierungsumgebung, das Kompilierungsergebnis, die Defender-Reaktion und Empfehlungen zur Risikominimierung.

Der Test war forschungsorientiert und wurde lokal auf einem dedizierten Testarbeitsplatz durchgeführt. Die Ergebnisse sind als Bewertung des Verhaltens eines bestimmten Artefakts und einer bestimmten Umgebungskonfiguration zu verstehen, nicht als vollständige Bestätigung der Widerstandsfähigkeit gegen alle möglichen Varianten dieser Technik.

Quellen, auf die im analysierten Material Bezug genommen wird:

• Artikel:

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

• Öffentliches PoC-Repository:

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

• MSYS2-Installer-Quelle:

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

• Visual Studio-Quelle:

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

Testumgebung

Der PoC wurde auf einem Client-Arbeitsplatz durchgeführt, der außerhalb einer Active Directory-Domäne in der Arbeitsgruppe WORKGROUP betrieben wurde. Das auf dem Arbeitsplatz installierte Betriebssystem war Microsoft Windows 11 Home, Version 25H2, 64-Bit-Architektur.

Am Tag der PoC-Durchführung waren auf dem System die Sicherheitsupdates vom Juni 2026 sowie frühere Updates vom Mai und April 2026 installiert. Das bedeutet, dass der Test auf einem aktuellen Windows 11 25H2-System mit Build 26200 nach Installation der neuesten verfügbaren Sicherheitspatches zum Testzeitpunkt durchgeführt wurde.

Microsoft Defender-Konfiguration

Microsoft Defender Antivirus war auf dem für den Test verwendeten Arbeitsplatz aktiv und lief im normalen Modus. Der Schutzdienst war ausgeführt und aktiviert, und der Virenschutz, der Antispyware-Schutz, die Verhaltensüberwachung und der Echtzeitschutz waren aktiv.

Am Testtag waren die Microsoft Defender-Signaturen auf dem neuesten Stand. Die Antivirus-, Antispyware- und NIS-Signaturen wurden am 10.06.2026 um 13:27:32 aktualisiert.

Der letzte Schnellscan wurde am 08.06.2026 von 15:00:36 bis 15:01:58 mit Signaturen der Version 1.451.323.0 durchgeführt. Ein vollständiger Scan wurde zuvor nicht durchgeführt, oder sein Verlauf war nicht verfügbar, wie der Wert von FullScanAge von 4294967295 und das Fehlen von Start- und Endzeiten für den vollständigen Scan zeigen.

Vorbereitung der Kompilierungsumgebung

Der erste Versuch, den Code aus dem GitHub-Repository zu kompilieren, endete mit einem Fehler aufgrund des fehlenden Headers winternl.h. Die Meldung wies darauf hin, dass das System nicht über den vollständigen Satz von Windows SDK-Headern verfügte, die der analysierte Code benötigt.

Abbildung 1. Fehler aufgrund des fehlenden winternl.h-Headers beim ersten Kompilierungsversuch.

Der Code referenzierte auch andere Header im Zusammenhang mit der Windows-API und der NT-API, darunter windows.h, Psapi.h, ntstatus.h, virtdisk.h, shlwapi.h, taskschd.h und bcrypt.h. Aus diesem Grund war es notwendig, eine vollständigere Kompilierungsumgebung vorzubereiten und die entsprechenden SDK-Komponenten zu installieren.

Abbildung 2. Ausschnitt der Liste der vom analysierten Code benötigten Header.

Versuch mit MSYS2/MinGW-w64

Zunächst wurde MSYS2/MinGW-w64 verwendet, um die Kompilierungsumgebung vorzubereiten. Diese Umgebung bietet GNU-Tools für Windows, einschließlich der Compiler gcc und g++. Pakete werden in MSYS2 mit pacman verwaltet, das eine ähnliche Rolle spielt wie apt unter Linux-Systemen oder winget unter Windows.

Abbildung 3. Abschluss der MSYS2-Installation.

Mit pacman wurde die MinGW-w64 GCC/G++-Toolchain installiert, d.h. eine Reihe von Tools, die die Kompilierung von C/C++-Code für Windows ermöglicht. Das Paket enthält unter anderem den gcc-Compiler, den g++-C++-Compiler, den Linker sowie die Header und Bibliotheken, die zum Erstellen von Anwendungen für die Windows-Umgebung erforderlich sind. Ziel dieses Versuchs war es zu prüfen, ob der Code mit der in MSYS2 verfügbaren offenen Toolchain ohne Verwendung von Visual Studio kompiliert werden kann.

Abbildung 4. Installation von MSYS2/MinGW-w64-Paketen mit pacman.

Nach der Installation wurde versucht, den Code mit g++ zu kompilieren. Der Befehl gab direkt den Pfad zur Quelldatei und den Pfad zur resultierenden ausführbaren Datei an.

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

Unicode-Modus-Problematik

Der erste deutliche Hinweis auf ein Problem mit dem Unicode-Modus waren die Compiler-Meldungen zu inkompatiblen Zeichentypen. Die Protokolle enthielten Fehler, die besagten, dass Werte vom Typ const wchar_t* oder wchar_t* nicht in LPCSTR oder LPSTR konvertiert werden konnten. Dies bedeutete, dass der Code Breitzeichenketten an Windows-API-Funktionen übergab, während der Compiler die für klassische ANSI-Zeichenketten vorgesehenen Funktionsvarianten auswählte.

In der Windows-API gibt es viele Funktionen in zwei Varianten: ANSI, gekennzeichnet durch das Suffix A, und Unicode, gekennzeichnet durch das Suffix W. Beispielsweise kann CreateFile als CreateFileA oder CreateFileW abgebildet werden, und RegOpenKeyEx als RegOpenKeyExA oder RegOpenKeyExW. Die A-Variante erwartet Parameter vom Typ char* oder LPCSTR, während die W-Variante Parameter vom Typ wchar_t* oder LPCWSTR erwartet.

Im analysierten Fall verwendete der Code Literale in der Form L"..." und Puffer vom Typ wchar_t. Gleichzeitig zeigten die Fehlermeldungen, dass der Compiler Funktionen wie GetModuleHandleA, RegOpenKeyExA, RegQueryValueExA, GetWindowsDirectoryA, CreateFileA und wsprintfA auswählte. Dies war ein direkter Hinweis darauf, dass der Code für den Unicode-Modus geschrieben war, das Kompilierungskommando jedoch weder UNICODE noch _UNICODE definierte.

Der Unicode-Modus wurde daher durch Hinzufügen der Definitionen UNICODE und _UNICODE erzwungen. Nach dieser Änderung sollten Windows-API-Funktionen ohne explizites Suffix auf die mit W suffigierten Varianten abgebildet werden, wie CreateFileW, RegOpenKeyExW, GetModuleHandleW und GetWindowsDirectoryW. Die Tatsache, dass einige der Fehler nach dieser Änderung verschwanden, bestätigte die Richtigkeit der Diagnose.

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

Nachdem die Unicode-bezogenen Probleme behoben waren, blieben jedoch Fehler bestehen, die auf eine tiefere Inkompatibilität zwischen dem Code und MinGW hinwiesen. Sie betrafen unter anderem doppelte Definitionen der Strukturen FILE_BASIC_INFORMATION und FILE_RENAME_INFORMATION, die sowohl im Quellcode als auch in den MinGW-Headern definiert waren. Darüber hinaus unterschied sich die in MinGW verfügbare Version von FILE_RENAME_INFORMATION von der vom Code erwarteten, insbesondere durch das Fehlen des Flags-Felds.

Weitere Fehler ergaben sich aus der restriktiveren Handhabung von Typen durch den g++-Compiler, insbesondere bei enum-Flags und Funktionszeigern. Dies betraf unter anderem die Typen VIRTUAL_DISK_ACCESS_MASK und ATTACH_VIRTUAL_DISK_FLAG sowie die Übergabe von Funktionszeigern als void*. Infolgedessen wurde MinGW als ungeeignet für die Kompilierung dieses Codes ohne erhebliche Änderungen am Quellcode eingestuft.

5. Migration zu MSVC und Windows SDK

Aufgrund von Kompatibilitätsproblemen mit MinGW wurde eine MSVC- und Windows-SDK-Umgebung vorbereitet. Im Visual Studio-Installer wurde die Workload "Desktopentwicklung mit C++" ausgewählt, da der analysierte Code eine native Windows-Anwendung war, die in C/C++ geschrieben war und direkt Windows-API- und Windows-SDK-Komponenten verwendete. Es handelte sich nicht um ein .NET-, Python-, Node.js- oder Webanwendungsprojekt, daher wurden Komponenten in Bezug auf diese Technologien nicht installiert.

Abbildung 5. Ausgewählte Visual Studio-Workload und Komponenten für Desktop-C++-Anwendungen.

Die wichtigste Komponente war MSVC v143, der Microsoft C/C++-Compiler für die Erstellung von C/C++-Anwendungen für Windows. Er wurde ausgewählt, weil der frühere Versuch, mit MinGW/G++ zu kompilieren, Kompatibilitätsfehler in Bezug auf Header, Typen und NT-API-Strukturen verursachte. Der Code verwendete Windows-spezifische Mechanismen, daher war die kompatibelste Umgebung der Microsoft-Compiler zusammen mit den vom Windows SDK bereitgestellten Bibliotheken.

Das Windows 11 SDK wurde ebenfalls installiert. Diese Komponente enthält die Header und Bibliotheken, die für die Verwendung von Windows-Systemfunktionen erforderlich sind, einschließlich windows.h, winternl.h, winreg.h, processthreadsapi.h, virtdisk.h und .lib-Importbibliotheken, die während des Linkens verwendet werden. Darüber hinaus wurden C++ CMake-Tools als Hilfskomponente beibehalten, die für die Analyse komplexerer Projekte nützlich sein können.

Nach der Installation wurde die x64 Native Tools-Eingabeaufforderung für VS Insiders verwendet – eine CLI mit den korrekten Pfaden für den cl.exe-Compiler, das Windows SDK und die Linker-Bibliotheken.

Abbildung 6. Starten der x64 Native Tools-Eingabeaufforderung für VS Insiders.

6. Kompilierung mit MSVC

Nach dem Wechsel zu MSVC kam der Code im Build-Prozess deutlich weiter. Der erste Befehl gab immer noch Fehler in Bezug auf die Zuordnung von Windows-API-Funktionen zu ANSI-Varianten aus, daher war es notwendig, die Definitionen UNICODE und _UNICODE auch bei der MSVC-Kompilierung hinzuzufügen.

cl /EHsc RoguePlanet.cpp -o rogue.exe

Abbildung 7. Kompilierungsversuch mit MSVC ohne vollständige Unicode- und Link-Konfiguration.

Nach dem Hinzufügen der Unicode-Schalter wurde der Code weiterverarbeitet, und Header- und Typkompatibilitätsfehler wurden durch LNK2019-Linkerfehler ersetzt. Dies bedeutete, dass der Compiler bereits eine Objektdatei erstellen konnte, während der Linker noch nicht alle vom verwendeten Windows-API-Funktionen benötigten Importbibliotheken erhalten hatte.

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

Abbildung 8. LNK2019-Linkerfehler für Windows-API-Funktionen.

Die Linker-Fehler betrafen Funktionen wie CreateProcessAsUserW, OpenProcessToken, AdjustTokenPrivileges, DuplicateTokenEx, GetTokenInformation, LookupPrivilegeValueW, RegOpenKeyExW und RegQueryValueExW. Diese Funktionen hängen mit Sicherheitstoken, Berechtigungen, dem Starten von Prozessen in einem bestimmten Benutzerkontext und dem Lesen der Systemregistrierung zusammen. Der Header deklariert lediglich, dass die Funktion existiert, aber der Linker muss die korrekte Importbibliothek erhalten, die angibt, wo sich die Implementierungen dieser Funktionen befinden.

Um die Linker-Fehler zu beheben, wurde die Bibliothek advapi32.lib hinzugefügt. Dies ist eine Windows-Importbibliothek, die unter anderem Funktionen im Zusammenhang mit Sicherheitstoken, Berechtigungen, Benutzerkonten und der Systemregistrierung bereitstellt. Nach dem Hinzufügen zur Link-Phase konnte der Linker die zuvor ungelösten externen Symbole auflösen und die ausführbare Datei erstellen.

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

Abbildung 9. Ergebnis des korrigierten Kompilierungsbefehls.

Abbildung 10. Ergebnis des erfolgreichen Befehls.

Abbildung 11. Erstellte rogue.exe-Datei im Arbeitsverzeichnis ~\Downloads\\

Microsoft Defender-Reaktion und Ausführungsergebnis

Während der Validierung wurde die erstellte ausführbare Datei sofort von Microsoft Defender als Trojan:Win64/RoguePlanet.DA!MTB mit dem Schweregrad "Schwerwiegend" erkannt. Das System schlug standardmäßige Schutzaktionen vor, wie das Verschieben der Datei in die Quarantäne oder das Löschen.

Abbildung 12. Windows-Meldung, die darüber informiert, dass die Datei als Virus oder potenziell unerwünschte Software blockiert wurde.

Abbildung 13. Microsoft Defender-Erkennung: Trojan:Win64/RoguePlanet.DA!MTB.

Dies bedeutet, dass die Erkennungsmechanismen von Defender das vorbereitete Artefakt als bösartig oder potenziell gefährlich identifizierten, bevor es erfolgreich ausgeführt werden konnte. Aus Sicht des Endpunktschutzes ist dies ein positives Ergebnis, da die Blockierung bereits auf der Ebene der ausführbaren Datei erfolgte und nicht erst nach Beobachtung der Auswirkungen der Programmausführung.

Nachdem der Echtzeitschutz vorübergehend deaktiviert wurde, konnte die Datei ausgeführt werden. Die Testbeobachtung deutet darauf hin, dass nach der zweiten Ausführung eine Konsole mit SYSTEM-Berechtigungen erlangt werden konnte. Dieses Ergebnis bestätigt, dass der aktive Defender-Schutz für die Blockierung des getesteten Artefakts entscheidend war.

Abbildung 14. Programmausführung in der Testumgebung nach Deaktivierung des Echtzeitschutzes.

Abbildung 15. Konsole, die im Systemkontext in der Testumgebung läuft.

Risikobewertung

Die Erkennung einer bestimmten Datei durch Microsoft Defender bedeutet nicht, dass das Schwachstellenrisiko vollständig beseitigt ist. Defender hat ein bekanntes oder ähnliches PoC-Artefakt erkannt, während eine modifizierte Version des Codes, eine andere Kompilierung, eine geänderte Dateistruktur oder ein anderer Lader sich in Bezug auf die signaturbasierte oder heuristische Erkennung anders verhalten könnten. Das Testergebnis sollte als Bestätigung der Wirksamkeit der aktuellen Schutzschicht gegen das getestete Artefakt betrachtet werden, nicht als Beweis dafür, dass jede mögliche Variation der Technik blockiert wird.

Gleichzeitig zeigt das Testergebnis, dass Defender bei aktivem Echtzeitschutz und aktuellen Signaturen das erstellte Artefakt erfolgreich blockiert hat. Das Risiko einer praktischen Ausnutzung steigt erheblich, wenn ein Benutzer in der Lage ist, den Echtzeitschutz zu deaktivieren, einen Ausschluss hinzuzufügen, eine erkannte Bedrohung zuzulassen oder die Schutzkonfiguration lokal zu ändern.

In der Praxis bedeutet dies, dass eine wirksame Gegenmaßnahme nicht allein auf das Vorhandensein von Defender selbst angewiesen sein sollte, sondern auch auf eine zentralisierte Durchsetzung seiner Konfiguration und die Blockierung lokaler Änderungen durch Benutzer.

9. Empfehlungen

Die zentralisierte Durchsetzung der Microsoft Defender-Konfiguration über Sicherheitsrichtlinien ist entscheidend. Lokale Benutzer sollten nicht in der Lage sein, den Echtzeitschutz zu deaktivieren, Ausschlüsse hinzuzufügen, erkannte Bedrohungen zuzulassen oder die Schutzeinstellungen zu ändern. In einem solchen Modell sollte der Benutzer nicht in der Lage sein, die Erkennung unabhängig zu umgehen, indem er eine Option wie "Auf Gerät zulassen" auswählt oder den Schutz vorübergehend deaktiviert.

• Zentralisieren Sie die Durchsetzung von Echtzeitschutz, cloudgeliefertem Schutz und automatischer Beispielübermittlung;

• Blockieren Sie Benutzern die Verwaltung von Ausschlüssen und Aktionen für Erkennungen;

• Überwachen Sie Defender-Ereignisse im Zusammenhang mit Erkennungen, Quarantäne, Versuchen, Bedrohungen zuzulassen, und Änderungen der Schutzkonfiguration;

• Behandeln Sie die Erkennung Trojan:Win64/RoguePlanet.DA!MTB als ein Sicherheitsereignis, das einer Analyse bedarf;

• Erwägen Sie zusätzliche Mechanismen zur Einschränkung der Ausführung nicht autorisierter ausführbarer Dateien, wie z. B. Anwendungs-Zulassungsauflistung, WDAC oder AppLocker, entsprechend den Fähigkeiten der Umgebung.

Abschließende Schlussfolgerungen

Der Test bestätigte, dass die Vorbereitung des Artefakts eine Umgebung erforderte, die mit der nativen Microsoft-Toolchain kompatibel ist. Der Kompilierungsversuch mit MinGW/G++ offenbarte Kompatibilitätsprobleme mit NT-API-Headern und -Strukturen, während der Wechsel zu MSVC und Windows SDK es ermöglichte, den Prozess bis zur Link-Phase fortzusetzen und schließlich nach Hinzufügen der korrekten Importbibliothek die ausführbare Datei zu erstellen.

Microsoft Defender im normalen Modus mit aktuellen Signaturen und aktiviertem Echtzeitschutz erkannte die erstellte Datei als Trojan:Win64/RoguePlanet.DA!MTB und blockierte ihre Ausführung. Dies ist aus Sicht des Endpunktschutzes ein positives Testergebnis.

Gleichzeitig ermöglichte die Deaktivierung des Echtzeitschutzes die Ausführung des Artefakts und führte zur Erlangung einer Konsole mit SYSTEM-Berechtigungen. Die praktische Schlussfolgerung ist klar: Die Defender-Konfiguration sollte zentral durchgesetzt werden, und Benutzer sollten nicht in der Lage sein, den Schutz lokal zu schwächen, Ausschlüsse hinzuzufügen oder erkannte Bedrohungen zuzulassen.