BlueHammer, RedSun, UnDefend: Drei Defender-Zero-Days in 18 Tagen – wenn die Schutzsoftware selbst zum Einfallstor wird

Was sich seit dem 10. April 2026 in Microsoft-Umgebungen abspielt, ist selbst für erfahrene Sicherheitsteams ungewöhnlich: Innerhalb von nur 18 Tagen hat ein Forscher-Duo unter den Pseudonymen Chaotic Eclipse und Nightmare Eclipse drei voneinander unabhängige Zero-Day-Schwachstellen in Microsoft Defender öffentlich gemacht – BlueHammer, RedSun und UnDefend. Alle drei werden inzwischen aktiv ausgenutzt. Microsoft hat bislang nur eine davon, BlueHammer, im April-Patch-Tuesday geschlossen. RedSun und UnDefend bleiben zum Zeitpunkt dieses Artikels offen, und CISA hat CVE-2026-33825 bereits in den Katalog der bekannten ausgenutzten Schwachstellen aufgenommen.

Das Besondere an dieser Sequenz: Die drei Schwachstellen sind nicht nur einzeln gefährlich. Aneinandergereiht ergeben sie ein vollständiges Offensiv-Toolkit. Privilegieneskalation, Codeausführung und vollständige Defender-Blindheit – alles über das Werkzeug, das eigentlich genau das verhindern soll. Für Verantwortliche im deutschen Mittelstand ist die Lage damit unangenehm klar: Ein verlässlich gepatchter Endpunkt-Schutz alleine reicht nicht mehr, wenn der Schutz selbst zum Angriffsvektor wird.

Worum es bei BlueHammer (CVE-2026-33825) geht

BlueHammer ist eine lokale Privilegieneskalation, die im Threat-Remediation-Engine von Windows Defender steckt. Die Wurzel ist eine klassische TOCTOU-Race-Condition (Time-of-Check to Time-of-Use): Defender prüft den Pfad einer Datei, bevor er privilegiert eine Operation darauf ausführt – aber zwischen Prüfung und Ausführung kann ein Angreifer den Pfad manipulieren. Konkret nutzt der Exploit einen batch opportunistic lock (oplock), um die Defender-Operation an einer kritischen Stelle anzuhalten. In dieser kurzen Pause legt der Angreifer einen NTFS-Junction-Point an und biegt das Ziel der bevorstehenden Defender-Operation auf C:\\Windows\\System32 um.

Das Ergebnis: Ein gewöhnlicher Benutzer eskaliert unauffällig auf NT AUTHORITY\\SYSTEM, indem er Defender selbst die privilegierten Schreibvorgänge erledigen lässt. Die CVSS-Bewertung liegt bei 7.8, der praktische Schaden ist erheblich. Microsoft hat den Fix als Teil des Patch Tuesday im April 2026 ausgerollt, CISA verlangt von US-Bundesbehörden eine Anwendung bis spätestens 6. Mai 2026. Für Unternehmen außerhalb der Bundesverwaltung gilt: Es gibt keinen vernünftigen Grund, hier länger als nötig zu warten.

RedSun – wenn Defender Dateien für den Angreifer wiederherstellt

RedSun ist die zweite, weiterhin ungepatchte Schwachstelle und folgt einem ähnlichen Muster, allerdings über einen anderen Defender-Mechanismus: die Cloud-Rollback-Funktion. Wenn Defender erkennt, dass eine Datei mit einem Cloud-Tag versehen ist, versucht er sie an ihren ursprünglichen Speicherort wiederherzustellen. Genau diese Wiederherstellung wird ausgenutzt – Defender prüft nicht ausreichend, wohin der ursprüngliche Pfad eigentlich zeigt. Über symbolische Verknüpfungen lässt sich auch hier der Schreibvorgang auf privilegierte Verzeichnisse umlenken. Im Ergebnis: Wieder eine lokale Privilegieneskalation, ausgelöst durch eine vermeintlich harmlose Aktion der Schutzsoftware.

Forscher von Huntress Labs haben RedSun bereits in echten Angriffen beobachtet, gemeinsam mit UnDefend, auf einem Windows-Host, der zuvor über einen kompromittierten SSL-VPN-Account übernommen worden war. Der Angreifer nutzte den initialen Zugang als Standardbenutzer und kombinierte beide Schwachstellen, um vollständige Kontrolle über das System zu erlangen.

UnDefend – Defender lügt das EDR an

UnDefend ist die vielleicht heimtückischste der drei Lücken, weil sie gar keine Privilegieneskalation braucht. Sie zielt auf die Update-Pipeline und den Kommunikationskanal des Defenders. Im passiven Modus blockiert UnDefend gezielt Signatur-Updates, sodass der Defender stillschweigend veraltet. Im aggressiven Modus deaktiviert er die Echtzeitprüfung vollständig. Und – das ist die eigentliche Brisanz – UnDefend manipuliert die Health-Telemetrie, die der Defender an Microsofts Cloud und an angeschlossene EDR-Konsolen meldet. Aus Sicht der zentralen Sicherheitsleitstelle wirkt der Endpunkt vollständig geschützt, während er in Wahrheit blind und stumm ist.

Für Unternehmen, die ihre Endpoint Protection per zentralem Dashboard überwachen, ist das ein Albtraumszenario: Die übliche Frühwarnung – ein offline gegangener Defender, fehlende Signatur-Updates, abgeschaltete Echtzeitprüfung – greift hier nicht mehr.

Warum die Kombination das eigentliche Problem ist

Einzeln betrachtet sind alle drei Schwachstellen ernst, aber beherrschbar. Gefährlich wird es in der Kette: Ein Angreifer, der über einen Phishing-Klick, einen kompromittierten VPN-Zugang oder eine ungepatchte Webanwendung initialen Zugriff erhält, startet typischerweise als Standardbenutzer. Mit BlueHammer (oder, falls gepatcht, mit RedSun) eskaliert er auf SYSTEM. Mit UnDefend stellt er sicher, dass Defender ihn nicht mehr behindert – und gleichzeitig nichts mehr meldet, was Sicherheitsanalysten alarmieren könnte. Anschließend kann er Tools nachladen, lateral bewegen, Zugangsdaten extrahieren und Persistenz aufbauen, ohne dass die zentrale EDR-Konsole etwas bemerkt.

Diese Kombination ist nicht theoretisch. Die drei Exploits wurden öffentlich auf einer Plattform veröffentlicht, die Forscher selbst als Protest gegen den Umgang von Microsofts MSRC mit Schwachstellenmeldungen bezeichnen. Die Schadcode-Bausteine sind also frei verfügbar – kein 0-Day-Markt, kein staatlicher Akteur nötig. Eine niederschwellige Nutzung durch Ransomware-Affiliates ist die naheliegende Folge.

Was IT-Teams jetzt sofort umsetzen sollten

Die wichtigste Sofortmaßnahme ist banal, aber essenziell: Alle Windows-Systeme auf den aktuellen April-2026-Patch-Stand bringen. CVE-2026-33825 ist damit geschlossen, und die Eskalationskette verliert ihren ersten Baustein. Wer Patch-Verzögerungen kennt – Wartungsfenster, Test-Pipelines, abgehängte Außenstellen –, sollte aktiv die nicht aktualisierten Hosts identifizieren und priorisiert ausrollen.

Da RedSun und UnDefend weiterhin ungepatcht sind, kommen Unternehmen mit reiner Patch-Disziplin nicht weiter. Mehrere kompensierende Maßnahmen lassen sich kurzfristig umsetzen: Härtung der initialen Angriffsfläche durch konsequente Multi-Faktor-Authentifizierung an allen VPN- und Remote-Zugängen, Aussortieren von Standardbenutzern aus Systemen, auf denen sie keine interaktiven Sitzungen brauchen, und engmaschige Überwachung der Defender-Telemetrie auf Anomalien wie plötzlich abreißende Signatur-Updates oder ungewöhnlich häufige Junction-Point-Erstellungen in Benutzerverzeichnissen. EDR-Lösungen, die nicht ausschließlich auf Defender-Signale vertrauen, sondern eigene Telemetrie sammeln, gewinnen in dieser Lage an Bedeutung.

Mittelfristig zeigt der Vorfall, wie verletzlich monokulturelle Schutzlandschaften sind. Wer ausschließlich Defender im Einsatz hat, verliert mit einer einzigen kompromittierten Komponente sowohl Schutz als auch Sichtbarkeit. Eine zweite, davon unabhängige Telemetriequelle – etwa ein netzbasiertes IDS, ein separates Logging-System mit eigener Integritätsprüfung oder ein dedizierter EDR-Agent neben Defender – ist daher kein Luxus, sondern Pflicht.

Was das für die NIS2-Pflichten bedeutet

Für Unternehmen im Geltungsbereich der NIS2-Umsetzung hat der Vorfall direkte regulatorische Implikationen. Die Pflicht zur frühzeitigen Meldung erheblicher Sicherheitsvorfälle bleibt bestehen – und die Frage, ob der Defender auf einem betroffenen Host korrekt funktioniert hat oder durch UnDefend manipuliert wurde, gehört zwingend in die forensische Aufarbeitung. Wer Schutzkomponenten nicht in seinem Risikomanagement führt, übersieht hier eine relevante Lücke. Die Anforderung des „Stand der Technik" ist nicht erfüllt, wenn man sich auf eine einzige, nun nachweislich umgangbare Schutzschicht verlässt.

Konkrete Handlungsempfehlungen

Wir empfehlen IT-Verantwortlichen ein abgestuftes Vorgehen. Kurzfristig: Patch-Status aller Endpunkte verifizieren, CVE-2026-33825 priorisiert ausrollen, MFA an allen Remote-Zugängen erzwingen, lokale Adminrechte auf Standardarbeitsplätzen entziehen, Defender-Telemetrie auf zentrale Logging-Systeme spiegeln und automatisiert auf fehlende Signatur-Updates und Defender-Health-Anomalien alarmieren. Mittelfristig: Eine zweite, davon unabhängige Erkennungsschicht etablieren – sei es netzbasiert, durch Application-Whitelisting oder durch einen ergänzenden EDR-Agent. Langfristig: Den eigenen Patch-Prozess, den Endpoint-Protection-Stack und die Telemetrie-Architektur in eine ehrliche Bewertung der eigenen Informationssicherheit einbetten und die Annahme „Defender läuft, also sind wir geschützt" durch eine messbare, mehrstufige Schutzlogik ersetzen.

Wenn Sie Ihren aktuellen Schutzstatus, Ihre Patch-Disziplin oder Ihre EDR-Strategie überprüfen lassen möchten, bevor die nächste Welle dieser Exploits Ihr Unternehmen erreicht: Sprechen Sie uns gerne über das Kontaktformular an. Drei Zero-Days in 18 Tagen sind keine Statistik, sondern eine konkrete Lageveränderung – und sie verdient eine ehrliche Reaktion.