Der "Zoff" zwischen einem Sicherheitsexperten, der sich Chaotic Eclipse oder Nightmare-Eclipse nennt, und Microsoft geht weiter. Er hat zum 12. Mai 2026 (pünktlich zum Patchday) wieder zwei 0-Day-Schwachstellen mit den Namen YellowKey (wirkt auf Bitlocker) und GreenPlasma (CTFMON EoP) öffentlich bekannt gemacht. Auch in Microsoft Teams ist eine Schwachstelle bekannt geworden, die Spoofing-Angriffe ermöglicht. Nach dem Patch ist also vor dem Patch und Microsoft sieht wieder alt aus.
Rückblick: Chaotic Eclipse ärgert sich über Microsoft
Der unbekannte Sicherheitsexperte Chaotic Eclipse (X-Handle @ChaoticEclipse0), auch unter dem Alias Nightmare-Eclipse auftretend, hatte Microsoft eine 0-day-Schwachstelle im Defender gemeldet. Microsoft gab aber die Rückmeldung erhalten, dass es keine Schwachstelle sei, die eine Bug-Bounty-Prämie rechtfertige.
Darauf hin hatte der verärgerte Sicherheitsexperte diese 0-day-Schwachstelle, die Windows und den Defender betrifft, zum 3. April 2026 samt Exploit veröffentlicht. Über die Schwachstelle konnten Angreifer sich Zugriff auf das System und Systemrechte verschaffen. Ich hatte im Blog-Beitrag BlueHammer: Windows 0-day-Schwachstelle berichtet.
Kurz darauf veröffentlichte der gleiche Sicherheitsexperte noch zwei weitere Schwachstellen, einmal RedSun samt 0-Day-Exploit, der jeder App auf einem Windows-System volle Systemadministratorrechte gewährt. Zudem wurde eine Schwachstelle mit Namen UnDefend zum Abschalten des Defenders offen gelegt. Ich hatte dies im RedSun: Nächste Windows Defender 0-Day-Schwachstelle aufgegriffen.
YellowKey und GreenPlasma-Schwachstellen
Die Nacht ist mir nachfolgender Tweet, der auf zwei neue, durch Chaotic Eclipse offen gelegte, 0-Day-Schwachstellen mit den Namen YellowKey und GreenPlasma hinweist, untergekommen.
Der Tweet fasst bereits die nachfolgend genannten, wichtigsten Kernpunkte bezüglich dieser auf X angekündigten Schwachstellen zusammen:
- YellowKey umgeht die BitLocker-Verschlüsselung unter Windows 11 und neueren Serverversionen, indem ein spezieller Ordner auf einen USB-Stick oder die EFI-Partition kopiert wird und anschließend durch Halten bestimmter Tasten beim Neustart vollständiger Zugriff auf das gesperrte Laufwerk erlangt wird.
- GreenPlasma ermöglicht Benutzern einen erweiterten Systemzugriff über eine CTFMON-Methode, die Windows 11 und einige Server betrifft. Hier hat man nur ein Teil des Codes als Herausforderung für andere Hacker veröffentlicht.
Die Erläuterungen von Chaotic Eclipse (aka Nightmare-Eclipse) finden sich in diesem Artikel, wobei er dort die obigen Links auf seine (inzwischen von GitHub auf GitHub verlagerte Seite mit den) veröffentlichten Details angegeben hat. Den Defender habe er ausgelassen, weil er wisse, dass Microsoft "die Zügel anziehen wird", wenn er zu oft auf eine bestimmte Komponente abzielt.
Ziemlich angefressener Sicherheitsexperte
Chaotic Eclipse scheint ziemlich angefressen zu sein, schreibt er in seiner Offenlegung doch: "Microsoft hat sich dafür entschieden, die Situation noch schlimmer zu machen, anstatt sie wie Erwachsene zu lösen; sie haben jedes nur erdenkliche kindische Spielchen gespielt. Meine Geduld ist am Ende, ihr lasst alle anderen dafür büßen."
Offenbar war Microsofts Reaktion auf die BlueHammer-Veröffentlichung nicht so, wie Chaotic Eclipse das erwartet hat – er schreibt von "Öl ins Feuer gießen" und hofft, dass Microsoft dieses Mal zumindest versucht, die Situation verantwortungsbewusst zu lösen.
Die jüngsten Handlungen Microsofts hätten Chaotic Eclipse dazu gebracht, andere Unternehmen mit in die Thematik zu involvieren. Der nächste Patch Tuesday werde eine große Überraschung für Microsoft bereithalten, droht er.
Analyse zu YellowKey-BitLocker-Bypass
Mir ist die Nacht auf X dieser Tweet von impulsive (@weezerOSINT) untergekommen, der den YellowKey-BitLocker-Bypass per Reverse-Engineering analysiert hat. Der Sicherheitsforscher schreibt, dass Microsoft in jedem Windows-11-Wiederherstellungsimage (WinRE) Code eingebaut habe, der nach einem Flag namens FailRelock sucht. Ist dieses auf 1 gesetzt, wird das BitLocker-Laufwerk nach der Wiederherstellung zwar entsperrt, aber nie wieder gesperrt. Man braucht dazu lediglich einen USB-Stick.
Dieser Code existiert nur in der Wiederherstellungsumgebung, nicht im normalen Windows. Microsoft habe ein komplettes Debug-Test-Framework in der Produktionsumgebung belassen, schreibt der Verfasser des Tweets.
Erste Analyse zu GreenPlasma
In einer Serie von Tweets auf X erklärt Het Metha die neue GreenPlasma genannte Schwachstelle im DTFMON Object-Cache.
CTFMON (ctfmon.exe) wird in jeder interaktiven Sitzung als SYSTEM ausgeführt und verwaltet mehrere benannte Objekte unter \Sessions\<id>\BaseNamedObjects. Darunter befindet sich auch CTF.AsmListCache.FMPWinlogon*. Da sich diese Objekte im Verzeichnis BaseNamedObjects der Sitzung befinden (in das SYSTEM schreiben kann), stellt die Manipulation der Objekterstellung ein leistungsstarkes Werkzeug für Angriffe dar. Die Kerntechnik (was der PoC tatsächlich tut) besteht aus Folgendem:
1. Missbraucht die Cloud Files-Richtlinienschlüssel (HKCU\Software\Policies\Microsoft\CloudFiles) mit einem flüchtigen REG_OPTION_CREATE_LINK + SymbolicLinkValue, der auf den eigentlichen Schlüssel „Policies\System" verweist.
2. Verwendet SetEntriesInAcl + TreeSetNamedSecurityInfo, um „Everyone" GENERIC_ALL zu gewähren, und setzt anschließend die DACLs zurück.
3. Ruft wiederholt CfAbortOperation (cldapi.dll) auf, um eine Neuinitialisierung zu erzwingen.
Das Ergebnis: Wenn CTFMON später sein Sektionsobjekt erstellt, landet es an einem Ort, auf den der Benutzer mit geringen Berechtigungen nun Einfluss nehmen kann. Details lassen sich in der Serie von Tweets nachlesen.
Auch Microsoft Teams mit Sicherheitslücke
Eine weitere, kürzlich bekannt gewordene, Sicherheitslücke in Microsoft Teams ermöglicht Hackern Spoofing-Angriffe. Die Schwachstelle offenbare eine kritische Schwäche im Design von Microsoft Teams, dass die Handhabung des Zugriffs auf Dateien und Verzeichnisse regelt, schreibt Cyber Security News. Dadurch können Angreifer potenziell vertrauenswürdige Elemente innerhalb der Anwendung manipulieren oder sich als diese ausgeben.
Im Kern rührt die Sicherheitslücke daher, dass Dateien oder Verzeichnisse in Microsoft Teams für externe Parteien zugänglich sind. Microsoft hat am 12. Mai 2026 die MS Teams Spoofing-Schwachstelle CVE-2026-32185 (CVSS 3.1 Score von 5.5) offen gelegt und gefixt.
Ähnliche Artikel:
BlueHammer: Windows 0-day-Schwachstelle
BlueHammer-Nachlese: Defender-Patch vom 14.4.2026 und Analyse von Fortra
RedSun: Nächste Windows Defender 0-Day-Schwachstelle
MVP: 2013 – 2016
Diese BitLocker-Geschichte klingt für mich wie eine bewusst platzierte Backdoor.
Der Gedanke drängt sich bei 'anschließend durch Halten bestimmter Tasten beim Neustart' geradezu auf. So ne Tastenabfrage erstellt sich ja nicht von selbst, das klingt nach ner Backdoor für Ermittlungsbehörden, die verschlüsselte Rechner beschlagnahmt hat.
Es ist eine Sache, Ermittlungsbehörden besondere Software zur Verfügung zu stellen. Diese Software aber ins Produkt einzubauen ist mMn höchst fahrlässig.
Fahrlässig?
Das ist wohl eher Vorsatz…
Und ein Grund mehr, dem Müll schnellstmöglich den Rücken zu kehren, wenn man halbwegs intelligent ist.
Naja, die Erklärung für die Tastenkombination lautet, "Microsoft habe ein komplettes Debug-Test-Framework in der Produktionsumgebung belassen." Kann man glauben, muss man aber nicht.
Würde das nicht so hoch hängen – Windows benötigt, so wie ich es in der Vergangenheit gelesen habe, einen Mechanismus, um die Bitlocker-Verschlüsselung bei bestimmten Update-Installationen temporär zu deaktivieren (das passiert teilweise bei der Installation in WinRE). Gab ja Fälle, von Microsoft als Bug dokumentiert, wo dann die Bitlocker-Verschlüsselung nicht mehr eingeschaltet wurde. US-Ermittlungsbehörden habe andere Möglichkeiten.
It's easy, either you want your data safe and use veracrypt or you want to lose your data permanently and then use bitclocker. Just look back a few months and it's repeated over and over again. Win won't start and asking for the key from the user who has no idea what's going on.
Ja, klingt nach Backdoor und ist wirklich bedenklich. Ob das aber auch funktioniert, wenn ein Bitlocker-Passwort gesetzt wird?
Ob "Chaotic Eclipse" für eine Festanstellung bei Microsoft (mit einem entsprechenden Maulkorb) bettelt? Der hat es anscheinend drauf.
Er hat da wohl Backdoors gefunden, nun denn. Da muss Microsoft wohl erst die Nutzer der Backdoors konsultieren, wie/wann usw. man das "behebt".
normalerweise wäre eine Fristsetzung der richtige Weg bevor man den exploit aufs Internet loslässt. schon ziemlich grenzwertiger "Sicherheitsexperte". wäre vielleicht mal gut wenn der Staatsanwalt anklopft.
Oder wenn man den Artikel einfach liest. Dort steht beschrieben, wie MS mit dem Sicherheitsexperten bzw. der Gruppe von Sicherheitsexperten bei der letzten Meldung umgegangen ist. Typisches Monolistengehabe halt… Immer her mit den Exploits, bis dieser Laden an seinem eigenen Müll erstickt und die Kunden endlich kapieren, was sie da für einen Müll einsetzen.
Sehe ich auch so ähnlich – das MSRT hat den Experten wohl mehrfach massiv "über den Löffel balbiert" und seine Eingaben verworfen.
Auf der einen Seite haben wir AI-Slop und seit Jahren eine vernachlässigte Sicherheitskultur bei diesem Unternehmen. Auf der anderen Seite gibt es jetzt LLMs, die man auf Windows ansetzen kann, um Schwachstellen zu finden und Exploits zu entwickeln.
Die Tage habe ich auf X noch einen Post gelesen, dass die 90-Tage-Offenlegungsfrist durch die KI-Entwicklung gerade schlicht pulverisiert wurde. Details unter the 90 day disclosure policy is dead
Schwachstelle ist im Falle von YellowKey meiner Meinung nach die falsche Bezeichnung. Wenn man sich die "Zutaten" anschaut und den Auslösemechanismus, dann kann man nur zum selben Schluss kommen wie der Entdecker, dass es sich um eine bewusst plazierte Umgehung des Bitlockermechanismus' handelt — wenn es denn exakt so funktioniert wie beschrieben. Ich habe es nicht geprüft.
Bei Schwachstellen denke ich immer zuerst an unwissentlich eingebaute Fehler. Kann man natürlich auch anders sehen.
Die Drohung, am nächsten Patchday eine Riesenüberraschung zu veröffentliches, lässt Schlimmes befürchten, wenn man sich die bisherigen 0-days so anschaut.
Der Schaden für die Welt wäre astronomisch, aber wenn mal ein Zerdo Day kommt, der Microsoft zwingt die Cloud komplett abzuschalten, wäre das der wohl einzige Weckruf den alle kapieren – Hersteller, Politik, Nutzer…
Leider sind wir an einem Punkt angelangt wo nur noch Lernen durch Schmerzen hilft – oder sollte man sagen Lernen durch Amputation?
Was für eine Welt…
" or should we say learning through amputation?"
Nope … through decapitation.
YellowKey: Auch wenn der Verdacht auf eine Backdoor in uns schlummert. So etwas würde man kontollierbar (also mit weiteren Schlüsseln) bauen. Man kann hier wohl von ungünstigen Umständen oder böse, von Schlamperei ausgehen. Aber ein Geschmäckle bleibt (denken wir an Dual_EC_DRBG, Juniper_ScreenOS-Backdoor oder undokumentierte Accounts bei Cisco).
Wer sagt denn, dass Schlapphüte nur fehlerfreie Anweisungen geben? 😉
Womöglich stammt das aus den Anfängen von Bitlocker. Damals hat man sich damit begnügt, dann das Thema verdrängt und somit später nie wieder dran geschraubt.
Eine Backdoor mit weiteren Schlüsseln wäre viel zu leicht auffindbar. Ernsthafte Varianten sind so konzipiert, dass Du sie auch bei oberflächlichem Code-Review nicht siehst.
> Zudem wurde eine Schwachstelle mit Namen UnDefend zum Abschalten des Defenders offen gelegt.
Abschalten des Defenders ist ja nichts Neues. Das machen Drittanbieter-Virenscanner ja auch (warum man sich ein weiteres Schlangenöl installiert, muss der Anwender selbst wissen).
Schwieriger wird's, wenn man den alternativen Scanner wieder deinstalliert und der Defender sich nicht mehr aktiviert und auch keine Signaturdateien mehr lädt. Hier passiert (in der Verwandtschaft). Reparieren ließ sich das nur durch eine Inplace-Reparatur.
Funktioniert das bei BitLocker auch, wenn der Rechner vorher heruntergefahren war oder nur nach einem Reboot aus dem entsperrten Zustand heraus?
Das funktioniert auch bei einem ausgeschalteten Win 11-Rechner! Test auf einem aktuellen System war erfolgreich.
Eigentlich unglaublich, dass das so einfach ist… das TPM rückt einfach den Bitlocker-Key heraus!
Rückt es ihn heraus oder ist Bitlocker falsch konfiguriert?
Was zeigt
manage-bde -protectors -get c:
an?
Bitte ohne Recoverykey. Nur die verwendeten PCRs beim TPM.
also, ich bin in der Shell (x:\windows\system32\cmd.exe) und kann auf mein (eigentlich verschlüsseltes) Laufwerk C:\ zugreifen!
Z.B. in C:\Windows\….
Den Wiederherstellungsschlüssel habe ich nicht eingegeben
wenn ich manage-bde -protectors -get C:
ausführe, dann kommt:
Volume „C:" [Windows]
Alle Schutzvorrichtungen
FEHLER: Ein Fehler ist aufgetreten (Code 0x80070057):
Falscher Parameter
Wenn ich nur manage-bde -status
aufrufe, dann zeigt er mir mein Volume „C:" [Windows] an mit:
Bitlocker-Version: 2.0
Verschlüsselungsmethode XTS-AES 256
Schutzstatus: Der Schutz ist aktiviert
Sperrungsstatus: Entsperrt
ID-Feld: Unbekannt
mein erster Gedanke war das in winre immer der Wiederherstellungsschlüssel benötigt wird und daher nichts "einfach so" offen ist. der Frage mit manage-bde würde ich mich anschließen und die Frage was du getestet hast?
Getestet habe ich mit einem USB-Stick bei dem ich die Dateien/Unterverzeichnisse azs dem Repository in \System Volume Information\FsTx\… kopiert habe.
Dann System 3x gebootet und immer wieder hart ausgeschaltet, damit WinRE kommt…
Zugriff auf die Platte ist mit dem eingesteckten USB-Stick ohne Eingabe des Recovery Key möglich…
Generell rückt das TPM den Schlüssel ja immer raus, solange nicht bestimmte Änderungen an Hardware oder BIOS-Einstellungen vorgenommen wurden, sonst wird der Wiederherstellungsschlüssel angefordert. Man kommt dann aber nur an die Daten ran, wenn man das Windows-Kennwort hat.
Korrekt – aber wenn WinRE (Shell) gestartet wird, dann wird auch entweder der Recovery Key abgefragt oder von Datei eingelesen, bevor man auf die Bitlocker-geschützte Partition/Disk zugreifen kann…
Mit YellowKey funktioniert das ohne… WinRE bootet auch gleich in die Shell, ohne dass irgendeine Auswahl (blaue Kacheloberfläche) kommt…
(das ist sehr unwahrscheinlich, dass das im Code „vergessen wurde" oder einfach ein Bug ist)
Betrifft wohl "Teams for Android".
Machts nicht viel besser, aber da Admins gerade viel zu tun haben, wäre ein Hinweis ganz gut:
The vulnerability specifically affects Microsoft Teams for Android, with the patched build number listed as 1.0.0.2026092103. Users are required to take action to apply the update available through the Google Play Store.
Jetzt hat MSFT YellowKey zumindest eine CVE-2026-45585 verpasst und gibt die offizielle Empfehlung wie man es zumindest entschärft:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45585
Beim Testen des Exploits empfehle ich vorsichtig zu sein. Unter bestimmten Bedingungen scheint die dadurch angestoßenen "Reparatur" des Filesystemes es dabei zu beschädigen. Das passiert zumindest hier mit einer Belegung eines USB-Sticks reproduzierbar.
Kopiert man den Exploit alleine auf einen leeren FAT32 Stick oder einen mit aktuellem W11 Recovery passiert ohne vorgeschlagene Mitigation, dass der Exploit gelöscht wird und conhost.exe statt bootim.exe in WinRE startet.
Deaktiviert man dagegen wie von MSFT vorgeschlagen autofstx.exe in der WINRE Registry bleibt der Exploit auf dem USB-Stick danach unverändert und es startet immer wie vorgesehen bootim.exe mit dem Menü.
Ich bin mal gespannt ob Eclipse jetzt mit seinem in einem Blog bereits angekündigten Exploit nachlegt, der angeblich wie auch immer selbst mit PIN funktionieren soll. Zuzutrauen wäre es ihm leider.
Man sollte also ggf. besser bis auf weiteres WinRE durch 'reagentc /disable' ganz deaktivieren um nicht kalt erwischt zu werden.
Außer CrowdStrike sollte statt dessen mit einem Falcon II Reloaded wieder scharf schießen. Dann dürfte man ganz ohne WinRE wirklich saudumm dastehen …