YellowKey-BitLocker-Bypass (05/2026): Wie WinRE, FsTx und FailRelock Windows-11-Geräte gefährden

Im Mai 2026 hat der Sicherheitsforscher Chaotic Eclipse, auf GitHub als Nightmare-Eclipse sichtbar, mit YellowKey einen öffentlich nachvollziehbaren Proof of Concept für einen BitLocker-Bypass veröffentlicht. Betroffen sein sollen nach Angaben des Forschers Windows 11 sowie Windows Server 2022 und 2025; Windows 10 soll sich in dieser Form nicht ausnutzen lassen. Der Angriff bricht nicht die BitLocker-Verschlüsselung, sondern missbraucht einen Zustand in der Windows-Wiederherstellungsumgebung WinRE.

Der Fall ist für Unternehmen und private Notebook-Nutzer relevant, weil BitLocker genau vor dem Verlust der physischen Kontrolle schützen soll. Ein gestohlenes oder kurz unbeaufsichtigtes Gerät darf seine Daten nicht preisgeben, nur weil jemand es einschalten, ein externes Medium anschließen oder eine Recovery-Umgebung starten kann. YellowKey zeigt erneut, dass Laufwerksverschlüsselung nicht isoliert funktioniert. Entscheidend sind TPM-Freigabe, BitLocker-Protectoren, WinRE, Firmware-Startreihenfolge, Wiederherstellungsmedien und die Frage, ob vor dem Windows-Start eine zusätzliche BitLocker-PIN verlangt wird.

Das Grundprinzip ist nicht „Verschlüsselung geknackt“, sondern „Vertrauensprüfung ausgetrickst“. Ein TPM-only geschütztes Gerät gibt den BitLocker-Schlüssel automatisch frei, wenn die gemessene Start- und Recovery-Umgebung für das System unverändert und vertrauenswürdig wirkt. YellowKey zielt darauf, genau diesen blinden Fleck auszunutzen: Das Gerät soll trotz manipulierter Recovery-Situation nicht in eine Recovery-Key-Abfrage laufen, sondern den TPM-gestützten Entsperrpfad regulär weiterverwenden. Kritisch wird also nicht ein schwacher Schlüssel, sondern ein Systemzustand, in dem Windows die Manipulation nicht als ausreichenden Anlass erkennt, BitLocker gesperrt zu halten.

Wichtig ist die Trennung von zwei Angriffslinien, die in vielen Berichten leicht ineinanderlaufen. CVE-2025-48804 und spätere Demonstrationen wie BitUnlocker betreffen vor allem Windows Boot Manager, SDI-/WIM-Ladevorgänge, alte signierte Bootkomponenten und Downgrade-Szenarien. YellowKey ist nach öffentlichem Stand anders gelagert: Der PoC rückt WinRE selbst in den Mittelpunkt und nutzt eine präparierte FsTx-Struktur, um einen Recovery-Zustand auszulösen, in dem ein BitLocker-Volume im laufenden WinRE-Kontext zugreifbar bleibt.

Die Veröffentlichung steht außerdem in einem offen ausgetragenen Konflikt. Chaotic Eclipse inszeniert seine Leaks seit Wochen als Eskalation eines Streits mit Microsoft. In seinem Blogbeitrag zu YellowKey und GreenPlasma wirft er Microsoft sinngemäß vor, die Lage verschlimmert und „kindische Spielchen“ gespielt zu haben. Öffentlich belegt sind seine eigenen Vorwürfe, die auf Patchdays terminierten Veröffentlichungen und die Abfolge mehrerer Zero-Day-Leaks.

Nach öffentlich verfügbaren Berichten ist plausibel, dass sich Chaotic Eclipses Spott über Microsofts angebliche „kindische Spielchen“ auch auf Reibung im MSRC-Prozess rund um Nachweisanforderungen beziehen könnte. Konkret kursiert seit BlueHammer die Darstellung, Microsoft habe eine Meldung nicht weiterbearbeitet oder abgewiesen, weil kein Video-Proof-of-Concept geliefert wurde. Diese Version wird unter anderem im G Data Blog als „angeblich“ beziehungsweise als begründete Vermutung eingeordnet; Howler Cell/Cyderes schreibt ebenfalls, der Konflikt sei Berichten zufolge eskaliert, nachdem der Forscher eine verlangte Videodemonstration nicht einreichen wollte. Will Dormann hatte bereits zuvor öffentlich kritisiert, dass MSRC einen klar beschriebenen Report ohne zugehöriges Video nicht akzeptieren wollte, und ordnete bei BlueHammer sinngemäß ein, dass ihn ein solches Vorgehen nicht überraschen würde. Microsoft hat den konkreten Ablauf im Fall Chaotic Eclipse jedoch nicht öffentlich bestätigt.

Was passiert bei dem Angriff?

YellowKey greift nicht AES, XTS-AES, den Volume Master Key oder den Full Volume Encryption Key an.

Sondern: Er greift die Umgebung an, in der Windows entscheidet, ob ein geschütztes Laufwerk während Start- und Wiederherstellungsvorgängen verfügbar wird. Sobald WinRE eine Shell oder einen privilegierten Dateizugriff öffnet, während das BitLocker-Volume bereits entsperrt ist, steht der Angreifer nicht mehr vor verschlüsselten Rohdaten. Er nutzt einen Zustand aus, den Windows selbst hergestellt hat.

Bei einem ausgeschalteten Windows-11-Gerät mit TPM-only-Schutz muss ein Angreifer nach dem öffentlich beschriebenen Modell nicht zuerst Windows anmelden oder den BitLocker-Wiederherstellungsschlüssel kennen. Der Angriff setzt darauf, dass TPM und Startmessung keinen entscheidenden Unterschied zwischen einer normalen Recovery-Situation und der manipulierten WinRE-Situation erkennen. Genau dadurch bleibt die erwartete Eskalation zur Recovery-Key-Abfrage aus oder wird nicht rechtzeitig erzwungen. Das TPM gibt nicht „falsch“ einen erratenen Schlüssel preis, sondern erfüllt regulär seine Aufgabe, weil das System die manipulative Umgebung als hinreichend gültig behandelt.

Der Auslöser ist eine präparierte Struktur unter System Volume Information\FsTx\95F62703B343F111A92A005056975458. System Volume Information ist kein normaler Benutzerordner, sondern ein geschützter Windows-Verwaltungsbereich für volume-nahe Metadaten.

WinRE beziehungsweise eine dort aktive Komponente verarbeitet im beobachteten Ablauf erreichbare \System Volume Information\FsTx-Strukturen und dabei NTFS-Transaktionszustände. Im beobachteten YellowKey-Ablauf führt das anscheinend dazu, dass X:\Windows\System32\winpeshl.ini entfernt oder unwirksam wird. Diese Datei steuert in Windows PE und WinRE, welche Shell nach dem Start geladen wird. Fehlt sie oder greift der erwartete Startpfad nicht, kann WinRE nicht die normale Wiederherstellungsoberfläche starten, sondern auf cmd.exe zurückfallen. Genau diese Eingabeaufforderung wird sicherheitskritisch, wenn das BitLocker-Volume im selben Recovery-Kontext bereits entsperrt ist. Siehe hierzu die Zusammenfassung bei BleepingComputer mit Einordnung von Will Dormann.

Eine Spur führt zu RecEnv.exe, der Windows-Recovery-Umgebung. Öffentlich diskutierte Reverse-Engineering-Ausschnitte zeigen eine Logik, die den Registry-Wert HKLM\SOFTWARE\Microsoft\RecoveryEnvironment\FailRelock ausliest. Der Name ist aussagekräftig: Er beschreibt einen Zustand, in dem das erneute Sperren eines zuvor zugreifbaren Volumes fehlschlägt oder als fehlgeschlagen behandelt wird. Wenn dieser Zustand aktiv ist, kann RecEnv.exe den Relock-Pfad überspringen. Das Volume bleibt dann nicht dauerhaft „unverschlüsselt“, sondern im laufenden WinRE-Kontext entsperrt und damit lesbar.

Der folgende dekompilierte Ausschnitt stammt von X-User @weezerOSINT.

Der gezeigte Ausschnitt ist C-ähnlicher Decompiler-Pseudocode aus RecEnv.exe, also kein originaler Microsoft-Quellcode, sondern rekonstruierte Programmlogik. Zuerst prüft die Funktion mehrere Bit-Flags in local_ac: Sind bestimmte Statusbits gesetzt oder fehlt ein erwartetes Basisbit, beendet sie den Ablauf sofort mit return 1. Anschließend bereitet der Code einen Registry-Lesevorgang vor und ruft RegGetValueW auf. Dabei liest RecEnv.exe aus HKLM\SOFTWARE\Microsoft\RecoveryEnvironment den DWORD-Wert FailRelock. Genau dieser Wert ist sicherheitsrelevant: Wenn FailRelock auf 1 steht, interpretiert die Recovery-Logik offenbar, dass das erneute Sperren eines zuvor entsperrten BitLocker-Volumes fehlgeschlagen ist oder nicht mehr durchgeführt werden soll. Danach folgt der kritische Zweig: Ist zusätzlich der interne Pointer-/Loop-Zustand erfüllt, springt die Funktion mit return 0 aus dem Relock-Pfad heraus. Programmiertechnisch bedeutet das: Der Code bricht nicht BitLocker, sondern überspringt die Logik, die das Volume im Recovery-Kontext wieder sperren müsste. Das Laufwerk bleibt also nicht dauerhaft „unverschlüsselt“, sondern innerhalb der laufenden WinRE-Sitzung entsperrt und damit über die anschließend erreichbare Shell lesbar.

Welche Voraussetzungen braucht ein Angreifer?

Wichtig ist die Abgrenzung zu einem Gerät, das bereits sichtbar in der BitLocker-Wiederherstellung steht und den 48-stelligen Recovery-Key verlangt. In diesem Zustand hat BitLocker die automatische TPM-Freigabe bereits verweigert, weil Startmessung, Protector-Bedingungen oder Recovery-Zustand nicht mehr als vertrauenswürdig gelten. Die öffentlich nachvollziehbare YellowKey-Variante setzt dagegen gerade darauf, dass diese Sperre nicht rechtzeitig greift: Das TPM-only-System gibt den Zugriff regulär frei oder hält ihn im WinRE-Kontext offen, obwohl die Recovery-Umgebung manipuliert wurde. Wenn die Recovery-Key-Abfrage bereits ausgelöst ist, liegt der Schlüssel nicht einfach zugreifbar bereit; dann bräuchte ein Angreifer den Recovery-Key oder eine zusätzliche, nicht öffentlich belegte Schwachstelle.

YellowKey ist kein typischer Remote-Angriff. Ein Angreifer braucht physische Kontrolle über das Zielgerät oder über dessen Startumgebung. Praktisch relevant wird das bei gestohlenen Notebooks, verlorenen Dienstgeräten, unbeaufsichtigten Admin-Laptops, gemeinsam genutzten Arbeitsplätzen, Laborgeräten, Besprechungsräumen, Hotelzimmern und überall dort, wo ein Gerät für kurze Zeit unbeobachtet bleibt.

Besonders gefährdet sind Systeme im TPM-only-Betrieb. Das bedeutet: BitLocker nutzt den Sicherheitschip des Geräts, entsperrt das Windows-Laufwerk aber automatisch, solange die Plattform vertrauenswürdig aussieht. Der Nutzer sieht vor dem Windows-Start keine zusätzliche BitLocker-Abfrage. Das ist bequem und schützt gut gegen den Ausbau der SSD. Es schützt schwächer gegen Angriffe auf das komplette Gerät, weil TPM, Firmware, Laufwerk und Recovery-Umgebung gemeinsam in den Händen des Angreifers liegen.

Für das Risiko ist entscheidend: Ein normal heruntergefahrenes TPM-only-Gerät muss nicht zuvor vom Angreifer mit Windows-Konto, Windows-Hello-PIN oder BitLocker-Recovery-Key geöffnet worden sein. Wenn der relevante Recovery-Pfad erreichbar ist und WinRE auf die präparierte Struktur reagiert, kann der Angriff beim nächsten Startversuch ansetzen. Der Angreifer versucht nicht, eine bestehende Windows-Sitzung zu übernehmen, sondern bringt das Gerät dazu, seine eigene TPM-basierte Freigabe in einer manipulierten Recovery-Situation zu akzeptieren.

• Physischer Zugriff auf ein Windows-11- oder Windows-Server-2022/2025-Gerät mit aktiviertem BitLocker.
• BitLocker-Freigabe ohne zusätzliche Authentifizierung vor dem Start, also typischerweise TPM-only.
• Eine aktive oder startbare Windows Recovery Environment, deren WinRE-Image die YellowKey-auslösende Komponente enthält.
• Ein beachteter Start- oder Datenträgerpfad, auf dem die präparierte FsTx-Struktur erreichbar ist.
• Unzureichend eingeschränkte externe Bootpfade, Firmware-Menüs, Recovery-Optionen oder EFI-Zugriffe.

Der öffentliche PoC ist deshalb ernst zu nehmen, weil er keinen Zugriff auf Windows-Anmeldedaten, kein Erraten des Recovery-Keys und keinen Angriff auf AES verlangt. Er nutzt aus, dass ein Gerät in einer Recovery-Situation selbst Zugriff auf sein geschütztes Volume organisiert. Organisationen müssen daher nicht nur fragen, ob BitLocker eingeschaltet ist. Sie müssen prüfen, wann der Schlüssel freigegeben wird, ob WinRE zuverlässig kontrolliert ist und ob ein Relock- oder Shell-Fehler den Schutz im falschen Moment offen lässt.

Warum eine BitLocker-PIN in diesem Fall wichtig ist

Nutzer verwechseln gelegentlich zwei völlig verschiedene PINs. Die Windows-Hello-PIN erscheint am Windows-Anmeldebildschirm. Sie schützt die Anmeldung, nachdem Windows bereits gestartet ist. Für den frühen BitLocker-Schutz zählt sie nicht, weil das Systemlaufwerk in einer TPM-only-Konfiguration zu diesem Zeitpunkt meist schon entsperrt wurde. Eine BitLocker-Start-PIN, oft auch TPM-PIN genannt, erscheint dagegen vor dem Windows-Start. Erst nach dieser Eingabe darf BitLocker den Startvorgang fortsetzen.

Genau deshalb ist die BitLocker-Start-PIN die wichtigste kurzfristige Härtung gegen die öffentlich reproduzierte YellowKey-Variante. Der Angreifer kann das Gerät nicht allein über TPM, WinRE und eine scheinbar zulässige Plattformumgebung zur Freigabe bewegen. Ohne die zusätzliche Eingabe bleibt das Systemvolume im kritischen Moment verschlüsselt. Eine Windows-Hello-PIN hilft hier nicht, weil sie viel später im Startablauf greift.

Trotzdem sollte niemand die Start-PIN als Freibrief verstehen. Die öffentlich reproduzierte YellowKey-Variante zielt vor allem auf TPM-only-Auto-Unlock. Chaotic Eclipse behauptet jedoch, eine nicht veröffentlichte Variante könne auch TPM-PIN-Szenarien betreffen. Belastbar bleibt daher: TPM plus BitLocker-Start-PIN reduziert das Risiko der öffentlichen Standardvariante erheblich. Zusätzlich müssen WinRE, Firmware, externe Bootpfade, Wiederherstellungsmedien und Recovery-Key-Prozesse sauber gehärtet werden.

Administratoren steuern die Start-PIN über die BitLocker-Richtlinien für Betriebssystemlaufwerke. Relevant ist die Richtlinie „Zusätzliche Authentifizierung beim Start anfordern“ unter Computerkonfiguration > Administrative Vorlagen > Windows-Komponenten > BitLocker-Laufwerkverschlüsselung > Betriebssystemlaufwerke. In verwalteten Umgebungen sollte die Richtlinie TPM plus PIN erlauben oder erzwingen und TPM-only für Geräte mit erhöhtem Schutzbedarf nicht als Standard akzeptieren.

Empfohlene Maßnahmen

Geräte mit erhöhtem Schutzbedarf sollten BitLocker nicht im reinen TPM-only-Modus betreiben. TPM plus BitLocker-Start-PIN bietet gegen die öffentlich nachvollziehbare YellowKey-Variante den größten unmittelbaren Sicherheitsgewinn. Diese PIN ist nicht die Windows-Hello-PIN am Anmeldebildschirm, sondern eine Abfrage vor dem Windows-Start. Genau dort muss zusätzlicher Schutz greifen, weil YellowKey und ältere Recovery-Angriffe vor oder neben dem normalen Windows-Login ansetzen.

Alle Systeme benötigen aktuelle Windows-Updates, aktuelle WinRE-Images und Firmware-Updates der Hersteller. Für YellowKey darf man ohne offizielle Bestätigung nicht behaupten, ein bestimmtes Update behebe die Schwachstelle bereits vollständig. Administratoren sollten daher Microsofts Security-Guidance, Hersteller-Firmware, WinRE-Stände und konkrete Hinweise zu RecEnv.exe, winpeshl.ini, FsTx-Verarbeitung und Recovery-Relock-Verhalten eng verfolgen.

Zusätzlich sollten Organisationen externe Bootpfade, PXE-Boot und Firmware-Menüs restriktiv konfigurieren. Ein Firmware-Passwort ersetzt keine BitLocker-Start-PIN, erschwert aber spontane Änderungen an Bootreihenfolge, Secure-Boot-Optionen und Recovery-Einstellungen. In Hochrisikoumgebungen sollten Geräte bei Verlust sofort als Sicherheitsvorfall gelten. Dann reichen Dateisystemfragen nicht aus: Zugangsdaten, Tokens, Zertifikate, Conditional-Access-Regeln, Sitzungen und lokale Geheimnisse müssen ebenfalls überprüft oder widerrufen werden.

Für Privatanwender mit geringem Expositionsrisiko bleibt ein vollständig aktualisiertes Windows-System mit aktivem BitLocker und Secure Boot sinnvoll. Wer jedoch vertrauliche Kundendaten, Admin-Zugänge, Quellcode, Forschungsdaten oder personenbezogene Informationen transportiert, sollte den Komfortmodus TPM-only nicht als ausreichenden Schutz betrachten. Verschlüsselung beginnt nicht erst beim Dateisystem. Sie beginnt beim ersten Code, dem ein Gerät nach dem Einschalten vertraut, und bei der Frage, ob ein Angreifer diesen Moment ohne zusätzliche Eingabe ausnutzen kann.