Security 19.05.2026 Aktualisiert: 16.06.2026

BlueHammer, YellowKey & Co.: Windows-Lücken richtig einordnen

Windows Defender, BitLocker und WinRE: Was zu BlueHammer, RedSun, UnDefend, YellowKey und GreenPlasma bekannt ist und was Admins prüfen sollten.

Stand: 16.06.2026, 18:00 Uhr CEST. Die Lage ist inzwischen deutlich offizieller als im Erststand: BlueHammer bleibt CVE-2026-33825 mit Defender-Plattform-Fix 4.18.26030.3011. Microsoft hat außerdem YellowKey als CVE-2026-45585, GreenPlasma-nahe CTF-Probleme als CVE-2026-45586, Mini-Plasma über einen Re-Release von CVE-2020-17103 und weitere Defender-Themen als CVE-2026-41091, CVE-2026-45498 sowie CVE-2026-50656 dokumentiert. Nicht jeder Forschername lässt sich sauber eins zu eins auf eine CVE mappen, aber “keine Microsoft-CVE” ist für mehrere Punkte nicht mehr korrekt.

Kurzfassung

Worum es geht: Ein Forscher unter den Namen Chaotic Eclipse beziehungsweise Nightmare-Eclipse hat mehrere Windows-Angriffe öffentlich gemacht. Betroffen sind unter anderem Microsoft Defender, BitLocker/WinRE, Cloud Files, CTF/Winlogon und cldflt.sys.
Nicht alles ist gleich belastbar. BlueHammer ist CVE-2026-33825, hat CVSS 7.8, ist in CISA KEV und wurde laut Microsoft/NVD durch Defender Antimalware Platform 4.18.26030.3011 adressiert. YellowKey, GreenPlasma und Mini-Plasma haben inzwischen MSRC-Einträge; RedSun/UnDefend-nahe Defender-Themen werden in Microsoft-CVEs zu Engine- und Plattformständen abgebildet.
Die Defender-Lücken sind lokale Angriffe. Ein Angreifer braucht bereits Code-Ausführung oder einen interaktiven Zugriff auf dem System. In echten Angriffen ist genau das aber nicht selten: kompromittierte VPN-Zugangsdaten, RDP, Phishing, Script-Ausführung, lokaler Benutzer, Helpdesk-Tool oder Malware-Staging.
YellowKey ist anders. Der BitLocker-Bypass braucht physischen Zugriff oder Zugriff auf bootnahe Datenträgerbereiche. Für verlorene Laptops, Außendienstgeräte, Server im fremden Rack und unbeaufsichtigte Workstations ist das deutlich relevanter als für einen Desktop im abgeschlossenen Büro.
Patching heißt hier nicht nur Windows Update. Bei BlueHammer zählt die Defender-Antimalware-Plattformversion. Bei späteren Defender-CVEs zählen zusätzlich Engine- und Plattformstände wie 1.1.26040.8 beziehungsweise 4.18.26040.7. KB2267602-Signaturen allein sind nicht automatisch der Plattform- oder Engine-Fix.
Für CISA-FCEB-Systeme ist BlueHammer überfällig. CISA setzte für CVE-2026-33825 den 06.05.2026 als Due Date. Wer am 19.05.2026 noch Defender-Plattformstände unter 4.18.26030.3011 findet, sollte das nicht in den normalen Monatszyklus schieben.
YellowKey ist jetzt offiziell CVE-2026-45585. Microsoft nennt es eine BitLocker-Security-Feature-Bypass-Schwachstelle mit physischem Angriff und empfiehlt eine WinRE-Mitigation, bis ein Security Update verfügbar ist. Microsoft sagt außerdem: TPM+PIN ist für diese CVE nicht ausnutzbar.
Für Admins zählt die Trennung: Defender-Plattform/Engine-Versionen, Windows-OS-Updates für Cloud-Files/CTF, WinRE-/BitLocker-Härtung und Incident-Hunting sind unterschiedliche Arbeitsstränge.

Was ist passiert?

Seit Anfang April 2026 veröffentlicht ein Forscher unter den Namen Chaotic Eclipse beziehungsweise Nightmare-Eclipse mehrere Windows-Angriffe öffentlich. Nach eigener Darstellung hatte er die Probleme an Microsoft gemeldet, war mit der Reaktion des Microsoft Security Response Center aber nicht einverstanden und stellte die Tools danach mitsamt Blogposts und GitHub-Repositories ins Netz. Das ist der Teil der Geschichte, der in Videos und Social Media hängen bleibt: angeblich ignorierte Meldungen, Streit um Bug-Bounty- und Disclosure-Prozesse, ein verärgerter Forscher, öffentliche PoCs und ausgerechnet GitHub als Ablageort für Windows-Exploits.

Ob Microsoft die Meldungen falsch behandelt hat, lässt sich von außen nicht sauber belegen. Microsoft hat aber inzwischen mehrere MSRC-Einträge veröffentlicht. Dadurch ist die Lage weniger spekulativ als Mitte Mai, aber immer noch unübersichtlich: Die öffentlichen Toolnamen, Forscherposts und CVE-Titel passen nicht immer sauber eins zu eins zusammen.

Für den Betrieb ist die Motivation trotzdem nur Hintergrundrauschen. Wir haben hauptsächlich eine Faktenlage: Einige Tools sind öffentlich verfügbar, einzelne Techniken wurden unabhängig analysiert, und Huntress hat BlueHammer-, RedSun- und UnDefend-nahes Tooling bereits in einem echten Intrusion-Kontext gesehen. Gleichzeitig ist nicht jede Behauptung aus dem Blog des Forschers automatisch ein bestätigtes Microsoft-Advisory.

Die Namen, die seit dem Mental-Outlaw-Video und den späteren Analysen besonders oft durcheinanderfliegen:

Name	Bereich	Status zum Stand dieses Artikels	Praktische Einordnung
BlueHammer	Microsoft Defender	CVE-2026-33825, CVSS 7.8, CISA KEV, Defender-Plattform-Fix `4.18.26030.3011`	Lokale Rechteausweitung über Defender-Workflow. Patch- und Detection-Priorität hoch.
RedSun	Microsoft Defender / Cloud Files / Remediation	MSRC führt CVE-2026-41091 als Microsoft-Defender-EoP, öffentlich bekannt und laut Microsoft mit Exploitation Detected. Fixanker ist Microsoft Malware Protection Engine `1.1.26040.8`.	Deutlich höher priorisieren als “nur PoC”: Engine-Stand inventarisieren und Hunting ernst nehmen.
UnDefend	Defender-Signatur-/Update-Störung	MSRC führt CVE-2026-45498 als Microsoft-Defender-Denial-of-Service, öffentlich bekannt und laut Microsoft mit Exploitation Detected. Fixanker ist Defender Antimalware Platform `4.18.26040.7`.	Für Incident Response relevant; alte Plattformstände schließen.
YellowKey	BitLocker / WinRE	CVE-2026-45585, Important, CVSS 6.8. Microsoft beschreibt einen physischen BitLocker-Bypass und stellt eine WinRE-Mitigation bereit; Security Update war laut CVE-Text noch nicht verfügbar.	Für gestohlene oder kurz physisch erreichbare Geräte sehr relevant; WinRE-Mitigation und TPM+PIN priorisieren.
GreenPlasma	Windows CTF / Winlogon / Cloud Files	CVE-2026-45586, Windows Collaborative Translation Framework EoP, CVSS 7.8, Publicly Disclosed, Exploitation More Likely.	Lokale EoP zu SYSTEM; Juni-Updates und Detection prüfen.
MiniPlasma	`cldflt.sys` / Cloud Files	Microsoft hat CVE-2020-17103 am 09.06.2026 erneut veröffentlicht und empfiehlt die Juni-2026-Windows-Updates, um die als Mini-Plasma bezeichnete Variante umfassend zu adressieren.	Nicht mehr nur Beobachtungsliste: Juni-2026-OS-Updates prüfen.
RoguePlanet	Microsoft Defender	CVE-2026-50656, Microsoft-Defender-EoP, CVSS 7.8, Publicly Disclosed, Exploitation More Likely. Microsoft arbeitet laut CVE-Text noch an einem Security Update.	Monitoring und MSRC-Status verfolgen; noch nicht als gefixt dokumentieren.

Für Admins zählt deshalb die Reihenfolge: Was ist bestätigt? Was ist gepatcht? Wo brauche ich Mitigation? Wo brauche ich Hunting?

BlueHammer: die belastbarste Lücke

BlueHammer ist der sauberste Teil der Geschichte, weil es dazu CVE-2026-33825 gibt. NVD beschreibt die Schwachstelle als unzureichende Zugriffskontroll-Granularität in Microsoft Defender. Ein lokaler, bereits autorisierter Angreifer kann dadurch Rechte lokal erweitern. Microsoft liefert den CVSS-3.1-Vektor AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, also lokal, niedrige Komplexität, niedrige Privilegien, keine Benutzerinteraktion, hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.

CISA hat CVE-2026-33825 am 22.04.2026 in den Known Exploited Vulnerabilities Catalog aufgenommen. Das ist wichtig: KEV heißt nicht “theoretisch interessant”, sondern CISA hat Hinweise auf Ausnutzung in freier Wildbahn.

Der Fix ist nicht einfach “irgendein Windows-Patch”. NVD führt Microsoft Defender Antimalware Platform-Versionen vor 4.18.26030.3011 als betroffen. Microsofts Defender-Release-Notes nennen für Windows Antivirus:

Komponente	Gefixter Stand laut Microsoft-Release-Notes
Platform	`4.18.26030.3011`, 14.04.2026
Engine	`1.1.26030.3008`, 08.04.2026
Security Intelligence	`1.449.16.0`, 14.04.2026

Der Microsoft Update Catalog führt KB4052623 als “Update for Microsoft Defender Antivirus antimalware platform” in Version 4.18.26030.3011, Current Channel Broad, zuletzt aktualisiert am 13.04.2026.

Das Detail ist im Betrieb wichtig: Viele Admins schauen bei Defender nur auf Security Intelligence Updates, also Signaturen. Für BlueHammer reicht das nicht als Nachweis. Du willst die Plattformversion sehen.

RedSun, UnDefend und neue Defender-CVEs

RedSun und UnDefend hatten im Erststand eine dünnere Quellenlage als BlueHammer. Huntress beschreibt BlueHammer, RedSun und UnDefend gemeinsam als Nightmare-Eclipse-Tooling und hat entsprechende Aktivität bei einer echten Untersuchung gesehen. Laut Huntress wurden die Tools in user-writable Pfaden abgelegt, daneben gab es typische Recon-Kommandos und Hinweise auf vorherigen Zugriff über kompromittierte FortiGate-SSL-VPN-Zugangsdaten.

Wichtig ist die Nuance: Huntress schreibt auch, dass die beobachtete Ausführung der Tools in diesem konkreten Fall offenbar nicht erfolgreich war. Das macht die Lage nicht harmlos. Es heißt nur, dass ein beobachteter Tool-Start nicht automatisch eine erfolgreiche SYSTEM-Übernahme beweist.

RedSun wird öffentlich als Defender-Remediation-/Cloud-Files-Race beschrieben: Defender soll beim Wiederherstellen oder Behandeln einer Datei in ein manipuliertes Ziel schreiben. UnDefend ist eher ein temporärer Defender-Störer: Es blockiert Signatur- oder Updatepfade über offene Handles. Wenn der Prozess beendet wird, fallen diese Locks weg und Defender kann sich erholen.

Microsoft hat die Lage inzwischen über zusätzliche Defender-CVEs greifbarer gemacht:

CVE	MSRC-Einordnung	Fix-/Statusanker
CVE-2026-41091	Microsoft Defender Elevation of Privilege, öffentlich bekannt, Exploitation Detected, CVSS 7.8.	Microsoft Malware Protection Engine vor `1.1.26040.8` betroffen; `1.1.26040.8` ist der erste adressierte Stand.
CVE-2026-45498	Microsoft Defender Denial of Service, öffentlich bekannt, Exploitation Detected, CVSS 4.0.	Defender Antimalware Platform vor `4.18.26040.7` betroffen; `4.18.26040.7` ist der erste adressierte Stand.
CVE-2026-50656	Microsoft Defender Elevation of Privilege, öffentlich bekannt, Exploitation More Likely, CVSS 7.8, öffentlich als RoguePlanet bezeichnet.	Microsoft arbeitet laut MSRC noch an einem Security Update; nicht als gefixt behandeln.

Für den Betrieb heißt das:

BlueHammer patchen und aktiv nach alten Defender-Plattformständen suchen.
Für CVE-2026-41091 zusätzlich die Malware-Protection-Engine-Version prüfen.
Für CVE-2026-45498 die Defender-Antimalware-Plattform mindestens auf 4.18.26040.7 bringen.
CVE-2026-50656/RoguePlanet beobachten, weil laut MSRC noch kein Security Update verfügbar ist.
Verdächtige Tool-Ausführung als Incident-Signal behandeln, nicht als “jemand hat nur einen PoC ausprobiert”.
Auf initialen Zugriff schauen. In Huntress’ Fall war der spannende Anfang nicht Defender, sondern mutmaßlich VPN-Zugang.

YellowKey: BitLocker und physischer Zugriff

YellowKey ist der Teil, der am meisten Aufmerksamkeit zieht. Das ist nachvollziehbar: BitLocker ist für viele Unternehmen die Antwort auf die Frage, ob ein verlorener Laptop ein meldepflichtiger Datenabfluss ist oder “nur” ein verlorenes Asset.

Der öffentliche YellowKey-Claim: Ein Angreifer mit physischem Zugriff kann über Windows Recovery Environment und eine vorbereitete Struktur Zugriff auf ein BitLocker-geschütztes Volume bekommen, ohne Recovery Key. Microsoft hat das Thema inzwischen als CVE-2026-45585 veröffentlicht: Windows BitLocker Security Feature Bypass, Important, CVSS 6.8, physischer Angriff, Publicly Disclosed, Exploitation More Likely. Tom’s Hardware berichtet eine eigene Reproduktion für das Default-Szenario. Blackfort ordnete das bereits vorher als potenziellen BitLocker-Recovery-Angriff ein; diese Grundrichtung ist durch den MSRC-Eintrag jetzt offizieller belegt.

Für Windows-11-Geräte mit Standard-BitLocker sollte man daraus keine pauschale Entwarnung ableiten. Das Threat Model muss überprüft werden. Besonders kritisch sind:

Laptops mit sensiblen Kundendaten, lokalen Secrets, VPN-Profilen oder Admin-Werkzeugen
Geräte von Geschäftsführung, IT, Buchhaltung und Außendienst
Geräte, die regelmäßig unbeaufsichtigt reisen
Systeme in Außenstellen, Laboren, Werkstätten oder fremden Racks
Windows-Server, bei denen physischer Zugriff durch Dritte realistischer ist als im eigenen abgeschlossenen Serverraum

TPM-only ist bequem, weil der Benutzer beim Booten nichts eingeben muss. Genau diese Bequemlichkeit ist aber eine Schwäche, wenn die Recovery-Umgebung oder die Bootkette missbraucht werden kann. TPM+PIN verschiebt die Grenze vor den automatischen Unlock. Microsoft schreibt in CVE-2026-45585 ausdrücklich, dass TPM+PIN für diese Schwachstelle nicht ausnutzbar ist. Praktisch bleibt TPM+PIN deshalb die wichtigste Härtung für gefährdete mobile Geräte.

Der MSRC-Eintrag enthält außerdem eine WinRE-Mitigation: autofstx.exe soll aus dem BootExecute-Wert der offline geladenen WinRE-Registry entfernt werden. Microsoft beschreibt dafür ein PowerShell-Skript, das WinRE mountet, den Offline-SYSTEM-Hive bearbeitet und WinRE anschließend wieder versiegelt. Das ist kein pauschaler Copy-Paste-Befehl für eine ganze Flotte. Es gehört in einen getesteten Endpoint-Management- oder Incident-Response-Workflow mit Recovery-Key-Escrow und Rollback-Plan.

GreenPlasma und MiniPlasma: lokale EoP-Fläche rund um Cloud Files und CTF

GreenPlasma ist keine fertige “Doppelklick und SYSTEM”-Kette im selben Sinn wie ein vollständiger Exploit. Die veröffentlichte Version wurde laut Analyse bewusst beschnitten. Trotzdem ist die primitive interessant: Object-Manager-Symlinks, CTF/Winlogon-Kontext und Registry-Link-Abuse über CloudFiles sind keine normalen Pfade, die man in einer Endpoint-Umgebung ständig sehen möchte.

Blackfort beschreibt als zentrale Beobachtungen unter anderem:

ein gezielt gesetztes Object-Manager-Symlink-Ziel im CTF-Kontext
Interaktion mit dem Winlogon-Desktop beziehungsweise SYSTEM-Kontext
Registry-Link-Artefakte unter CloudFiles\BlockedApps
SymbolicLinkValue als stärkeres Signal als generische Werte wie DisableLockWorkstation
ungewöhnliche cldapi.dll-Nutzung außerhalb typischer OneDrive-/Cloud-Files-Prozesse

Microsoft hat GreenPlasma und Mini-Plasma inzwischen ebenfalls besser einordenbar gemacht, auch wenn die öffentlichen Namen weiter vorsichtig zu verwenden sind.

CVE-2026-45586 ist ein Windows Collaborative Translation Framework Elevation of Privilege mit CVSS 7.8. Microsoft beschreibt Link-Following vor Dateizugriff; ein erfolgreicher Angreifer kann SYSTEM-Rechte bekommen. Der Eintrag ist öffentlich bekannt und von Microsoft als “Exploitation More Likely” bewertet.

Mini-Plasma wird von Microsoft über CVE-2020-17103 wieder aufgegriffen. Dieser alte Windows Cloud Files Mini Filter Driver EoP wurde am 09.06.2026 erneut veröffentlicht; Microsoft empfiehlt die Juni-2026-Windows-Updates, um die als Mini-Plasma bezeichnete Variante umfassend zu adressieren. Für den Betrieb heißt das: nicht nur Defender-Komponenten prüfen, sondern auch die normalen Juni-2026-OS-Updates auf betroffenen Windows-Clients und Servern.

Wie schlimm ist das für produktive Umgebungen?

Die kurze Einschätzung: ernst, aber unterschiedlich dringend.

Umgebung	Risiko	Priorität
Unternehmensendpoints mit Defender aktiv	BlueHammer, CVE-2026-41091, CVE-2026-45498 und RoguePlanet/CVE-2026-50656 hängen an Defender-Plattform, Engine und MSRC-Status.	Hoch: Defender-Plattform- und Engineversion inventarisieren, alte Stände schließen und RoguePlanet weiter beobachten.
Geräte mit kompromittiertem VPN/RDP/Benutzerzugang	Lokale EoP-Tools werden genau dort praktisch.	Sehr hoch: Nicht nur patchen, sondern Incident Response.
Laptops mit Windows 11 und TPM-only BitLocker	YellowKey betrifft das physische Verlust-/Diebstahl-Szenario.	Hoch bei sensiblen oder mobilen Geräten.
Windows Server 2022/2025 mit physisch kontrollierter Umgebung	YellowKey ist weniger wahrscheinlich, Defender-LPE und Cloud-Files/CTF-EoP bleiben bei lokalem Zugriff relevant.	Mittel bis hoch, je nach Benutzer- und Zugriffssituation.
Terminalserver, Entwickler-Workstations, Build-Systeme	Lokale Rechteausweitung ist dort besonders unangenehm.	Hoch, weil viele lokale Ausführungspfade existieren.
Einzelplatz-PC zu Hause	Relevant, aber meistens weniger dramatisch als bei Firmenendpoints.	Normal patchen, BitLocker-Konfiguration prüfen.
Systeme ohne Defender als aktives AV	Defender-CVEs hängen an installierten Komponenten; Scanner können Dateien auch bei deaktiviertem Defender melden. Microsoft weist darauf hin, dass deaktivierte Defender-Umgebungen nicht automatisch exploitable sind.	Status prüfen: Defender aktiv/passiv/deaktiviert sauber unterscheiden und trotzdem Komponenten aktuell halten.

Der häufigste Denkfehler wäre: “Ist lokal, also egal.” Lokale Lücken sind genau das, was nach einem ersten Einstieg verwendet wird. Ein Phishing-Payload, ein kompromittiertes VPN-Konto oder ein normaler Benutzerkontext ist noch nicht Domain Admin. Eine zuverlässige lokale Rechteausweitung kann daraus den nächsten Schritt machen.

Bei BitLocker ist die praktische Antwort nicht Resignation, sondern Härtung: TPM+PIN, WinRE-Kontrolle, Bootreihenfolge, UEFI-Passwort, Secure Boot, saubere Recovery-Key-Verwaltung und weniger lokale Secrets reduzieren den Schaden deutlich.

Schnellprüfung: Defender-Version

Auf einem einzelnen System:

Get-MpComputerStatus |
  Select-Object AMRunningMode,
                AMProductVersion,
                AMEngineVersion,
                AntivirusSignatureVersion,
                AntivirusSignatureLastUpdated,
                RealTimeProtectionEnabled,
                IsTamperProtected

Für BlueHammer ist vor allem AMProductVersion relevant. Als Mindeststand für CVE-2026-33825 gilt 4.18.26030.3011. Für die neueren Defender-Stände kommt mehr dazu:

Thema	Feld	Mindeststand / Status
BlueHammer, CVE-2026-33825	`AMProductVersion`	`4.18.26030.3011`
CVE-2026-41091	`AMEngineVersion`	`1.1.26040.8`
CVE-2026-45498	`AMProductVersion`	`4.18.26040.7`
RoguePlanet, CVE-2026-50656	MSRC-Status	laut Microsoft am 16.06.2026 noch ohne Security Update

Ältere Plattform- oder Engine-Stände sollten nicht mit “Signaturen sind aktuell” abgetan werden.

Wenn die Plattform nicht aktuell ist:

Update-MpSignature

Update-MpSignature aktualisiert primär Security Intelligence und kann, wenn die Updatequellen passen, auch Defender-Komponenten nachziehen. Als alleiniger Nachweis für BlueHammer reicht der Befehl aber nicht. Entscheidend bleibt danach der gemessene Wert von AMProductVersion.

Ein einfacher Compliance-Ausdruck für lokale Prüfungen:

$MinimumBlueHammerPlatform = [version]'4.18.26030.3011'
$MinimumUnDefendPlatform = [version]'4.18.26040.7'
$MinimumDefenderEngine = [version]'1.1.26040.8'
$Status = Get-MpComputerStatus

[pscustomobject]@{
  ComputerName     = $env:COMPUTERNAME
  AMRunningMode    = $Status.AMRunningMode
  AMProductVersion = $Status.AMProductVersion
  AMEngineVersion  = $Status.AMEngineVersion
  BlueHammerFixed  = ([version]$Status.AMProductVersion -ge $MinimumBlueHammerPlatform)
  PlatformJunFixed = ([version]$Status.AMProductVersion -ge $MinimumUnDefendPlatform)
  EngineJunFixed   = ([version]$Status.AMEngineVersion -ge $MinimumDefenderEngine)
}

Für eine kleine Flotte mit PowerShell Remoting:

$MinimumBlueHammerPlatform = [version]'4.18.26030.3011'
$MinimumUnDefendPlatform = [version]'4.18.26040.7'
$MinimumDefenderEngine = [version]'1.1.26040.8'
$Computers = Get-Content .\endpoints.txt

Invoke-Command -ComputerName $Computers -ScriptBlock {
  $Status = Get-MpComputerStatus
  [pscustomobject]@{
    ComputerName     = $env:COMPUTERNAME
    AMRunningMode    = $Status.AMRunningMode
    AMProductVersion = $Status.AMProductVersion
    AMEngineVersion  = $Status.AMEngineVersion
    BlueHammerFixed  = ([version]$Status.AMProductVersion -ge [version]'4.18.26030.3011')
    PlatformJunFixed = ([version]$Status.AMProductVersion -ge [version]'4.18.26040.7')
    EngineJunFixed   = ([version]$Status.AMEngineVersion -ge [version]'1.1.26040.8')
    SignatureVersion = $Status.AntivirusSignatureVersion
  }
} | Sort-Object PlatformJunFixed, EngineJunFixed, AMProductVersion | Export-Csv .\defender-platform-engine-june-2026.csv -NoTypeInformation

In WSUS-, MECM-, Intune- oder Proxy-Umgebungen muss geprüft werden, ob KB4052623 beziehungsweise Defender Platform Updates wirklich freigegeben und erreichbar sind. Microsoft beschreibt KB4052623 als monatliche Platform Updates. In WSUS/MECM ist das ein typischer Stolperstein: Signaturupdates können sauber laufen, während die Plattformupdates nicht genehmigt, nicht synchronisiert oder durch falsche Updatequellen blockiert sind.

Typische Fallen:

KB2267602 ist primär Security Intelligence. Das ist nicht automatisch der Plattform-Fix.
In WSUS/MECM müssen Defender-Produktupdates beziehungsweise die passende Microsoft-Defender-Antivirus-Kategorie synchronisiert und genehmigt sein. Nicht nur nach “Windows Defender” oder nur nach Security-Intelligence-Updates suchen.
KB4052623 kann in WSUS mehrfach mit unterschiedlichen Versionen auftauchen, weil Microsoft Platform Updates phasenweise veröffentlicht.
Wenn WSUS die Quelle ist, müssen die Updates genehmigt sein. Ein Client, der nur auf WSUS zeigt, holt sich den Plattform-Fix nicht automatisch direkt bei Microsoft Update.
Defender kann im Passive Mode laufen, wenn ein anderes AV aktiv ist. Das kann Scanner irritieren.
Offline- oder streng proxied Server bleiben gerne auf alten Plattformständen hängen.
Golden Images, Snapshots und selten gestartete Server können alte Defender-Komponenten konservieren.
Ein Windows-Cumulative-Update beweist nicht automatisch den aktuellen Defender-Plattformstand.

Wenn der normale Updatepfad klemmt, gibt es drei sinnvolle Eskalationswege:

KB4052623 im Microsoft Update Catalog passend zu Betriebssystem und Architektur herunterladen und gezielt installieren.
Updatequellen für Defender korrigieren und danach Update-MpSignature beziehungsweise den geplanten Defender-Updatezyklus erneut laufen lassen.
Als Break-Glass-Schritt MpCmdRun.exe -SignatureUpdate aus der aktuellen Defender-Plattform ausführen und danach trotzdem AMProductVersion prüfen:

$PlatformRoot = Join-Path $env:ProgramData 'Microsoft\Windows Defender\Platform'
$LatestPlatform = Get-ChildItem $PlatformRoot -Directory |
  Sort-Object Name -Descending |
  Select-Object -First 1

& (Join-Path $LatestPlatform.FullName 'MpCmdRun.exe') -SignatureUpdate

Die betriebliche Regel bleibt gleich: erst Plattformstand messen, dann Updatequelle korrigieren, dann erneut messen.

Schnellprüfung: BitLocker, WinRE und Pre-Boot-Schutz

Für YellowKey geht es weniger um einen klassischen Patchstand, sondern um Konfiguration und physisches Risiko.

Get-BitLockerVolume |
  Select-Object MountPoint, VolumeStatus, ProtectionStatus, EncryptionPercentage, KeyProtector

Zusätzlich:

manage-bde -protectors -get C:
reagentc /info

Worauf du achten solltest:

Ist das OS-Volume wirklich geschützt?
Nutzt das Gerät nur TPM, oder TPM+PIN?
Ist WinRE aktiviert, und wo liegt das WinRE-Image?
Sind Recovery Keys sauber in Entra ID, AD DS oder einem anderen kontrollierten Escrow abgelegt?
Gibt es lokale Admins, lokale Secrets, VPN-Profile, RDP-Dateien, SSH-Keys oder Browser-Secrets, die nach einem physischen Zugriff besonders weh tun?

WinRE pauschal zu deaktivieren ist keine schöne Standardlösung. reagentc /disable kann Recovery-Workflows, OEM-Reparaturpfade und bestimmte Update-/Rollback-Szenarien beeinträchtigen. Für besonders gefährdete Geräte kann es als temporäre Maßnahme sinnvoll sein, aber nicht als blinder GPO-Hammer für alle Clients.

Für CVE-2026-45585 ist der konkrete Microsoft-Mitigation-Anker WinRE selbst: Der BootExecute-Wert im offline gemounteten WinRE-SYSTEM-Hive darf autofstx.exe nicht mehr starten. Das sollte über getestetes Endpoint-Management erfolgen, nicht durch manuelles Herumeditieren auf produktiven Laptops ohne Recovery-Key-Nachweis.

Pragmatischer ist diese Reihenfolge:

Hochrisiko-Geräte identifizieren: Geschäftsführung, IT-Admins, Außendienst, Reisen, sensible Daten.
TPM+PIN für diese Gruppen testen und ausrollen.
Boot von externen Medien im UEFI sperren, UEFI-Passwort setzen, Secure Boot erzwingen.
Recovery-Key-Escrow prüfen.
WinRE-Härtung oder temporäres Deaktivieren nur nach Test und Rollback-Plan.

Für ein einzelnes Testgerät sieht der TPM+PIN-Weg grob so aus. Vorher muss der Recovery Key sauber in Entra ID, AD DS oder im vorgesehenen Escrow liegen. Sonst baust du dir bei einem Tippfehler oder Firmwareproblem unnötig ein Recovery-Thema.

manage-bde -protectors -get C:
manage-bde -protectors -add C: -TPMAndPIN
manage-bde -protectors -get C:

Wenn danach ein sauberer Neustart mit PIN funktioniert und der Recovery-Key geprüft ist, kann der alte TPM-only-Protector entfernt werden:

manage-bde -protectors -delete C: -type tpm
manage-bde -protectors -get C:

Das sollte nicht blind auf eine ganze Flotte losgelassen werden. Erst ein Pilot mit mehreren Hardwareklassen, Tastaturlayouts und Docking-/Pre-Boot-Szenarien. Enhanced PINs sind praktisch, aber Microsoft weist selbst darauf hin, dass nicht jede Pre-Boot-Umgebung alle Zeichen sauber unterstützt. Für viele Umgebungen ist ein numerischer PIN als erster Schritt weniger riskant.

Der zentrale Gruppenrichtlinienpfad ist:

Computer Configuration >
Administrative Templates >
Windows Components >
BitLocker Drive Encryption >
Operating System Drives >
Require additional authentication at startup

Dort muss für TPM-Geräte nicht nur TPM erlaubt sein, sondern Require startup PIN with TPM passend gesetzt werden. In Intune liegt dasselbe Thema unter den BitLocker-/Endpoint-Security-Richtlinien beziehungsweise über den BitLocker-CSP SystemDrivesRequireStartupAuthentication. Wichtig ist, vorher Ausnahmen wie “Allow devices compliant with InstantGo or HSTI to opt out of preboot PIN” zu prüfen, weil solche Policies eine Pre-Boot-PIN-Pflicht praktisch wieder aushebeln können.

Hunting: wonach man suchen sollte

Wenn ein System nur alt gepatcht ist, ist das Vulnerability Management. Wenn du Hinweise auf Tool-Ausführung siehst, ist es Incident Response.

Huntress nennt bei der beobachteten Aktivität unter anderem Tool-Namen und Pfade wie:

FunnyApp.exe
RedSun.exe
undef.exe
z.exe
Ausführung aus Benutzerprofilen, etwa Pictures oder kurzen Unterordnern unter Downloads
Defender-Detection Exploit:Win32/DfndrPEBluHmr.BZ
Recon-Kommandos wie whoami /priv, cmdkey /list und net group
verdächtige Tunnel- oder Proxy-Ausführung über agent.exe

Das sind keine vollständigen IoCs für alle Angriffe. Sie sind aber gut genug, um bestehende EDR-/SIEM-Daten rückwirkend zu durchsuchen.

Beispielhafte lokale Eventlog-Sichtung auf einem betroffenen Einzelhost:

Get-MpThreatDetection |
  Select-Object InitialDetectionTime, ThreatName, Resources, ActionSuccess |
  Sort-Object InitialDetectionTime -Descending

Für GreenPlasma-artige Spuren sind Sysmon oder EDR-Telemetrie deutlich hilfreicher als Standard-Windows-Logs. Sinnvolle Signale:

Registry-Artefakte unter CloudFiles\BlockedApps
SymbolicLinkValue unter diesem Pfad
ungewöhnliche cldapi.dll-Loads außerhalb erwartbarer OneDrive-/Cloud-Files-Prozesse
auffällige Handles oder Injection-nahe Zugriffe auf ctfmon.exe
ungewöhnliche Kindprozesse von ctfmon.exe
Winlogon-/UAC-/LockWorkStation-Abläufe in zeitlicher Nähe zu verdächtigen Prozessen

Für YellowKey ist klassisches Endpoint-Hunting schwieriger, weil der spannende Teil vor oder in der Recovery-Umgebung passiert. Trotzdem lohnt sich:

Suche nach verdächtigen FsTx-Strukturen auf Datenträgern und EFI-Partitionen
Kontrolle von Boot-/Recovery-Änderungen
Geräteverlust ernsthaft als potenziellen Datenzugriff bewerten, wenn Windows 11 mit TPM-only im Spiel ist

Ein vorsichtiger lokaler Check auf sichtbare FsTx-Strukturen:

Get-PSDrive -PSProvider FileSystem | ForEach-Object {
  $path = Join-Path $_.Root 'System Volume Information\FsTx'
  if (Test-Path $path) {
    Write-Warning "Auffällige FsTx-Struktur gefunden: $path"
    Get-ChildItem -Force $path | Select-Object FullName, Length, CreationTime
  }
}

Dieser Check ist kein Beweis für Ausnutzung und kein vollständiger Scanner. Er hilft nur, eine auffällige Struktur nicht zu übersehen.

Was beim Patchen wichtig ist

Für Windows-Umgebungen würde ich die Maßnahmen in drei Spuren trennen.

1. Defender-Plattform schließen

Für CVE-2026-33825:

Defender Antimalware Platform mindestens 4.18.26030.3011.
KB4052623 beziehungsweise Defender Platform Updates in WSUS/MECM/Intune prüfen.
Nicht nur Signaturen prüfen.
Nach dem Rollout mit Get-MpComputerStatus validieren: AMProductVersion muss mindestens 4.18.26030.3011 sein.
Server und selten genutzte Clients nicht vergessen.
Geräte im Passive Mode separat bewerten, damit Schwachstellenscanner nicht falsche Sicherheit oder falsche Panik erzeugen.

2. Lokale EoP-Ketten erschweren

Für RedSun, GreenPlasma, MiniPlasma und ähnliche lokale Ketten:

Windows-Updates sowie Defender-Plattform und Defender-Engine aktuell halten.
Standardbenutzer statt lokale Admins erzwingen.
App Control, WDAC oder AppLocker für kritische Rollen prüfen.
ASR-Regeln nicht nur “enabled” nennen, sondern Block-/Audit-Modus kontrollieren.
EDR/SIEM-Regeln auf user-writable Execution, Defender-Tooling und CTF/CloudFiles-Artefakte nachziehen.
VPN/RDP/Remote-Access-Logs in denselben Incident-Kontext nehmen.

3. BitLocker-Threat-Model anpassen

Für YellowKey:

Windows-11-Geräte mit TPM-only BitLocker inventarisieren.
TPM+PIN für Hochrisiko-Gruppen testen und ausrollen.
Recovery-Key-Escrow vor der Umstellung nachweisen.
Nach erfolgreichem Pilot den alten TPM-only-Protector entfernen, damit nicht parallel weiterhin ein automatischer Unlock-Pfad bleibt.
UEFI-Bootreihenfolge sperren, USB-Boot deaktivieren, UEFI-Passwort setzen.
Secure Boot und Bootzertifikat-Status prüfen.
WinRE-Konfiguration dokumentieren.
Recovery Keys zentral sichern und Zugriff darauf protokollieren.
Lokale Secrets reduzieren: keine dauerhaft gespeicherten Admin-Credentials, keine privaten Schlüssel ohne Zusatzschutz, keine unnötigen VPN-Profile.

Das klingt nach viel, ist aber sauberer als “BitLocker abschalten” oder “WinRE überall deaktivieren”. Verschlüsselung bleibt sinnvoll. Sie muss nur zur Bedrohung passen.

Wie wir damit umgehen würden

Bei einem Kunden mit Windows-Endpoints, Servern und Microsoft-365-/Entra-Umgebung würde ich nicht zuerst über die PoC-Details diskutieren. Ich würde den Zustand der Umgebung ziehen:

Defender-Plattform- und Engineversionen inventarisieren.
Alte Stände unter 4.18.26040.7 bei der Plattform und unter 1.1.26040.8 bei der Engine priorisiert aktualisieren; RoguePlanet/CVE-2026-50656 weiter über MSRC beobachten.
EDR/SIEM rückwirkend nach Huntress-nahen Artefakten durchsuchen.
VPN-, RDP- und Remote-Support-Logs auf ungewöhnliche Logins prüfen.
Windows-11-BitLocker-Konfigurationen nach TPM-only und TPM+PIN aufteilen.
Hochrisiko-Geräte zuerst auf TPM+PIN und UEFI-Härtung bringen.
WinRE nicht blind deaktivieren, sondern pro Gerätegruppe bewerten.
Bei konkreten Tool-Spuren: Incident Response, Credential-Prüfung und laterale Bewegung suchen.

Wenn du Windows-Clients, Server oder Admin-Workstations betreibst und nicht sicher bist, ob Defender-Updates, BitLocker-Policies und Recovery-Key-Ablage sauber sind, ist ein kurzer Security-Hardening-Check sinnvoller als hektisches Umschalten einzelner Einstellungen. Gerade bei Laptops und Admin-Geräten hängt viel davon ab, ob die Konfiguration wirklich zum Risiko passt.

Update-Log

2026-04-02: Laut öffentlicher Berichterstattung wurde BlueHammer von Nightmare-Eclipse/Chaotic-Eclipse veröffentlicht.
2026-04-12: UnDefend wurde auf dem Blog des Forschers angekündigt.
2026-04-14: Microsoft veröffentlichte CVE-2026-33825; Defender Antimalware Platform 4.18.26030.3011 ist der relevante Fixstand für BlueHammer.
2026-04-15: RedSun wurde vom Forscher veröffentlicht.
2026-04-20: Huntress veröffentlichte eine Analyse zu Nightmare-Eclipse-Tooling in einem echten Intrusion-Kontext.
2026-04-22: CISA nahm CVE-2026-33825 in KEV auf, mit FCEB-Fälligkeitsdatum 06.05.2026.
2026-05-12: YellowKey und GreenPlasma wurden vom Forscher angekündigt.
2026-05-13: Der Forscher behauptete, RedSun sei still gepatcht worden, und ergänzte Aussagen zu YellowKey und TPM+PIN.
2026-05-14: Blackfort veröffentlichte eine technische GreenPlasma-Analyse; der Forscher ergänzte Aussagen zu YellowKey/GreenPlasma.
2026-05-15: MiniPlasma wurde vom Forscher angekündigt.
2026-05-18/19: Das Thema bekam durch das Mental-Outlaw-Video zusätzliche Reichweite außerhalb der engeren Windows-Security-Bubble.
2026-05-19: Artikelentwurf angelegt. BlueHammer gegen NVD, Microsoft-Release-Notes, Microsoft Update Catalog, CISA-KEV-Hinweise und Huntress abgeglichen; YellowKey/GreenPlasma gegen unabhängige Analysen und öffentliche Berichte eingeordnet.
2026-06-09: Microsoft veröffentlichte CVE-2026-45586 für Windows Collaborative Translation Framework und veröffentlichte CVE-2020-17103 erneut mit Bezug auf Mini-Plasma und Juni-2026-Windows-Updates. CVE-2026-45585 wurde mit WinRE-Mitigation und TPM+PIN-Aussage aktualisiert.
2026-06-16: Microsoft veröffentlichte CVE-2026-50656 für RoguePlanet/Microsoft Defender. Artikel auf MSRC-Stand aktualisiert: Defender-Engine 1.1.26040.8, Defender-Plattform 4.18.26040.7, YellowKey/WinRE-Mitigation, GreenPlasma/CTF und Mini-Plasma/Juni-Updates ergänzt.