Am 11./12. August 2026 veröffentlichte der Forscher Nightmare Eclipse (auch bekannt unter dem Handle MSNightmare) den Proof-of-Concept ShieldBreak. Der Exploit soll den im Juli 2026 veröffentlichten Microsoft-Patch für die Defender-Schwachstelle RoguePlanet (CVE-2026-50656) vollständig umgehen und auf aktuellen Systemen – Windows 11 25H2 (inkl. Canary-Kanal) sowie Windows Server 2025 – mit angeblich 100 % Erfolgsrate SYSTEM-Rechte verschaffen.

Unabhängige Bestätigungen durch Kevin Beaumont und Will Dormann zeigen, dass der PoC funktioniert, solange Microsoft Defender aktiv ist. Windows 10 und die zugehörigen Server-Editionen gelten laut Forscher ebenfalls als anfällig, werden vom aktuellen PoC jedoch noch nicht unterstützt.

Hintergrund: Von RoguePlanet zu ShieldBreak

Technischer Vergleich

„RoguePlanet was a filesystem race condition vuln that uses virtual disks and NT native file manipulation to trick quarantine process into overwriting system files. ShieldBreak [is a] user-mode callback hook to change file contents during a Defender cloud-hydration scan via cfapi (Cloud Filter API).“

— Kevin Beaumont

Detaillierter Ablauf des ShieldBreak-Exploits

Der PoC kombiniert mehrere legitime Windows-Mechanismen zu einer Angriffskette. Im Folgenden die wichtigsten Phasen in der Reihenfolge, wie sie im Quellcode und in öffentlichen Analysen erkennbar sind.

1. Vorbereitung und Cloud-Provider-Registrierung

   Der Exploit erzeugt ein verstecktes Arbeitsverzeichnis unter C:\ShieldBreak_<GUID> und registriert dort einen eigenen Cloud-Sync-Provider mit dem Namen „Flubber“ (CfRegisterSyncRoot). Anschließend wird ein Placeholder namens BERLIN angelegt (CfCreatePlaceholders). Der eigentliche Dateiinhalt existiert zu diesem Zeitpunkt noch nicht – er wird erst bei der Hydration über einen Callback geliefert.

2. Object-Manager-Namespace-Manipulation

   Über undokumentierte bzw. wenig genutzte NT-APIs (NtCreateDirectoryObjectEx, NtCreateSymbolicLinkObject) werden Object-Directories und Symbolic Links im Restricted-Namespace (\BaseNamedObjects\Restricted\) erzeugt. Dabei kommen Shadow-Directories zum Einsatz. So entsteht ein Pfad, der aus Sicht von Defender auf den Placeholder zeigt, aber zur Laufzeit umgebogen werden kann. Ein typischer Scan-Pfad sieht in etwa so aus:

   \\.\globalroot\BaseNamedObjects\Restricted\WD_SHADOW_<GUID>\WD_SCAN\BERLIN

3. Trigger des Defender-Scans + EICAR-Bait

   Über die MpClient-Schnittstelle (MpManagerOpen, MpScanStart mit Resource-Scan) wird ein gezielter Scan auf den präparierten Pfad gestartet. Sobald Defender die Datei hydratisieren will, liefert der CfApi-Callback zunächst den Inhalt der eingebetteten EICAR-Test-Datei (aus der Resource eicar_com.zip). Defender erkennt die Bedrohung und leitet Remediation-Maßnahmen ein.

4. Inhaltswechsel und Pfad-Redirect während der Remediation

   In der Cleanup-/Quarantäne-Phase wechselt der Callback den gelieferten Inhalt: Statt EICAR wird nun die Payload-DLL (Warden.dll) ausgeliefert (Restart-Hydration). Parallel werden die Object-Manager-Symlinks umgestellt. Über einen UNC-Loopback-Pfad (\\127.0.0.1\C$) und einen Alternate Data Stream (:stream) landet die Datei schließlich als C:\Windows\System32\phoneinfo.dll. Da Defender mit SYSTEM-Rechten arbeitet, ist das Schreiben an diesen Ort möglich.

5. Lock, WER-Task und Payload-Aktivierung

   Die gepflanzte Datei wird per CreateFileMapping mit dem Flag SEC_IMAGE gemappt und dadurch gelockt. Anschließend wird die Windows-Error-Reporting-Aufgabe „QueueReporting“ (unter \Microsoft\Windows\Windows Error Reporting) über den Task Scheduler gestartet. Über eine Named Pipe (\\.\pipe\SHIELDBREAK) koordiniert der PoC die weitere Ausführung. Die Payload (Warden.dll) kann so in einem privilegierten Kontext aktiv werden. Am Ende meldet der PoC „Exploit succeeded.“ und räumt temporäre Artefakte auf.

Warum der bisherige Patch nicht greift

Der RoguePlanet-Fix adressierte primär die Race-Condition im Zusammenhang mit virtuellen Datenträgern, Junctions und dem klassischen Quarantäne-Pfad. ShieldBreak wählt einen anderen Angriffsvektor:

• Die Cloud Filter API erlaubt es einem registrierten Provider, den Dateiinhalt erst bei der Hydration zu liefern und diesen Inhalt dynamisch zu ändern.
• Der Object Manager ermöglicht es, Pfade aus Sicht anderer Prozesse (hier Defender) umzuleiten, ohne dass klassische NTFS-Junction-Checks greifen.
• Die Remediation von Defender läuft mit hohen Privilegien – ein einmal umgeleiteter Schreibvorgang kann daher Systemdateien erzeugen.

Es handelt sich daher eher um eine neue Angriffstechnik als um einen klassischen „Patch-Bypass“ derselben Root-Cause. Der Forscher bezeichnet den PoC dennoch als vollständigen Bypass, weil der bestehende Schutzmechanismus die neue Kette nicht verhindert.

Auswirkungen und Erkennung

Ein erfolgreicher Exploit eleviert von einem normalen Benutzerkonto auf NT AUTHORITY\SYSTEM. Es sind weder Kernel-Exploit noch Memory-Corruption erforderlich – Defender selbst wird zum Privilegien-Vehikel. Der Angriff erfordert lediglich, dass Defender aktiv ist und der Nutzer den PoC (oder eine abgeleitete Variante) ausführen kann.

Empfehlungen für Administratoren

• Solange kein offizieller Fix vorliegt: Die von Kevin Beaumont bereitgestellten Detections und Hunting-Queries in Microsoft Defender for Endpoint bzw. vergleichbare EDR-Lösungen einspielen.
• Systeme, bei denen Defender durch eine andere Antivirus-Lösung vollständig deaktiviert ist, sind von diesem spezifischen Vektor nicht betroffen.
• Monitoring der Erstellung neuer Cloud-Filter-Provider und ungewöhnlicher Object-Manager-Objekte im Restricted-Namespace.
• Engine-Version der Malware Protection Engine im Blick behalten und Windows-Updates zeitnah einspielen, sobald Microsoft nachlegt.

Fazit

ShieldBreak unterstreicht erneut, wie gefährlich die Kombination aus privilegierten Systemkomponenten (Defender) und mächtigen, aber komplexen Windows-APIs (Cloud Filter API + Object Manager) sein kann. Die Veröffentlichung erfolgt vor dem Hintergrund anhaltender Spannungen zwischen dem Forscher und Microsoft – einschließlich früherer rechtlicher Drohungen.

Bis zu einem offiziellen Fix bleibt die Angriffsfläche bestehen. Organisationen sollten die genannten Verhaltensmuster engmaschig überwachen und die Engine-Version sowie Cloud-Filter- und Object-Manager-Aktivitäten besonders im Blick behalten.