Security 19.05.2026 Aktualisiert: 19.05.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: 19.05.2026, 03:08 Uhr CEST. Von den öffentlich diskutierten Nightmare-Eclipse-/Chaotic-Eclipse-Lücken ist BlueHammer als CVE-2026-33825 offiziell greifbar und in CISA KEV gelistet. Microsoft nennt als gefixte Defender-Antimalware-Plattform 4.18.26030.3011. RedSun, UnDefend, YellowKey, GreenPlasma und MiniPlasma sind zum geprüften Stand deutlich unsauberer einzuordnen: Es gibt öffentliche PoCs, unabhängige Analysen und einzelne Reproduktionen, aber nicht für alles ein Microsoft-Advisory oder eine CVE.

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. Bei RedSun, UnDefend, YellowKey, GreenPlasma und MiniPlasma fehlen zum Teil offizielle Microsoft-Details.
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. KB2267602-Signaturen allein sind nicht automatisch der Plattform-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.
TPM+PIN ist kein perfekter Beweis, aber eine sinnvolle Sofortmaßnahme. Der aktuell öffentliche YellowKey-PoC scheint an TPM+PIN zu scheitern; der Forscher behauptet eine nicht veröffentlichte Variante. Praktisch bleibt TPM+PIN trotzdem die richtige Härtung für gefährdete mobile Geräte.
Für Admins zählt die Trennung: bestätigte CVE und Patchstand bei BlueHammer, vorsichtige Bewertung bei YellowKey, und Detection/Hunting bei den übrigen Tools.

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 bei BlueHammer aber später tatsächlich CVE-2026-33825 veröffentlicht. Bei anderen Namen aus derselben Serie fehlt so eine offizielle Zuordnung bislang. Dadurch entsteht die unübersichtliche Lage: Ein Teil ist bestätigter Patchfall, ein Teil ist öffentliche Research, ein Teil ist Behauptung des Forschers.

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	Öffentliches PoC, laut Forscher später still gepatcht; keine belastbare CVE im geprüften Material	Ernst nehmen, aber im Artikel klar als nicht offiziell sauber dokumentiert markieren.
UnDefend	Defender-Signatur-/Update-Störung	Öffentliches Tool, von Huntress in Intrusion-Kontext gesehen; eher temporäre Störung als dauerhafte Persistenz	Für Incident Response relevant, allein weniger dramatisch als BlueHammer/RedSun.
YellowKey	BitLocker / WinRE	Öffentliches PoC, unabhängige Reproduktion für Default-BitLocker-Szenarien berichtet; keine offizielle Microsoft-CVE im geprüften Material	Für gestohlene oder kurz physisch erreichbare Geräte sehr relevant.
GreenPlasma	Windows CTF / Winlogon / Cloud Files	Öffentliches, bewusst unvollständiges PoC; unabhängige technische Analyse vorhanden	Lokale EoP-Vorstufe. Detection lohnt sich, Panik weniger.
MiniPlasma	`cldflt.sys` / Cloud Files	Am 15.05.2026 veröffentlicht, laut Forscher gegen gepatchte Windows-11-/Server-2025-Systeme getestet	Noch frischer und dünner belegt; als Update-Kandidat beobachten.

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 und UnDefend: weniger sauber, trotzdem relevant

RedSun und UnDefend haben 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.

Für den Betrieb heißt das:

BlueHammer patchen und aktiv nach alten Defender-Plattformständen suchen.
RedSun/UnDefend nicht ignorieren, nur weil es keine schöne CVE-Seite gibt.
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. Betroffen sollen Windows 11, Windows Server 2022 und Windows Server 2025 sein; Windows 10 scheint nach bisherigen Analysen nicht betroffen zu sein. Tom’s Hardware berichtet eine eigene Reproduktion für das Default-Szenario. Blackfort ordnet das als potenziellen BitLocker-Recovery-Angriff ein und weist korrekt darauf hin, dass eine offizielle Microsoft-Bestätigung zum Zeitpunkt der Analyse fehlt.

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. Der veröffentlichte YellowKey-PoC scheint an TPM+PIN zu scheitern. Der Forscher behauptet eine private TPM+PIN-Variante; unabhängig belegt ist das zum Stand dieses Artikels nicht. Deshalb ist TPM+PIN keine Entwarnung, aber eine sinnvolle Sofortmaßnahme.

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

MiniPlasma kam danach noch dazu und soll cldflt.sys beziehungsweise Cloud-Files-Logik betreffen. Zum geprüften Stand ist das Thema noch zu frisch für belastbare Aussagen zu Fixstand, betroffenen Versionen und realer Ausnutzung. Es gehört aber in die Beobachtungsliste, weil es dieselbe größere Angriffsfläche berührt: Windows Cloud Files, Recovery-/Shell-Kontexte und lokale Privilege-Escalation-Ketten.

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 ist relevant, wenn die Defender-Plattform alt ist. RedSun/UnDefend sind Hunting-Themen.	Hoch: Defender-Plattformversion inventarisieren und alte Stände schließen.
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 bleibt 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	BlueHammer ist laut Microsoft/NVD an Defender gebunden; Scanner können Dateien trotzdem als verwundbar melden.	Status prüfen: Defender aktiv/passiv/deaktiviert sauber unterscheiden.

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. Ältere Plattformstä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:

$MinimumDefenderPlatform = [version]'4.18.26030.3011'
$Status = Get-MpComputerStatus

[pscustomobject]@{
  ComputerName     = $env:COMPUTERNAME
  AMRunningMode    = $Status.AMRunningMode
  AMProductVersion = $Status.AMProductVersion
  IsFixed          = ([version]$Status.AMProductVersion -ge $MinimumDefenderPlatform)
}

Für eine kleine Flotte mit PowerShell Remoting:

$MinimumDefenderPlatform = [version]'4.18.26030.3011'
$Computers = Get-Content .\endpoints.txt

Invoke-Command -ComputerName $Computers -ScriptBlock {
  $Status = Get-MpComputerStatus
  [pscustomobject]@{
    ComputerName     = $env:COMPUTERNAME
    AMRunningMode    = $Status.AMRunningMode
    AMProductVersion = $Status.AMProductVersion
    IsFixed          = ([version]$Status.AMProductVersion -ge [version]'4.18.26030.3011')
    SignatureVersion = $Status.AntivirusSignatureVersion
  }
} | Sort-Object IsFixed, AMProductVersion | Export-Csv .\defender-platform-bluehammer.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.

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 und Defender-Plattform 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-Plattformversionen inventarisieren.
Alte Stände unter 4.18.26030.3011 priorisiert aktualisieren.
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.