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) 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 von YellowKey ist kurz gesagt nicht „Verschlüsselung geknackt“, sondern „Vertrauensprüfung ausgetrickst“. Ein TPM-only geschütztes Gerät (der übliche Standardsetup) 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.

Die Veröffentlichung steht 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 entsperrt BitLocker das Systemlaufwerk vor dem Windows-Login automatisch, sobald TPM und Bootmessung die Startumgebung als vertrauenswürdig einstufen. YellowKey setzt an diesem frühen Entsperrzeitpunkt an: Die manipulierte WinRE-Situation wirkt für die Schutzlogik offenbar noch zulässig, sodass keine BitLocker-Recovery-Key-Abfrage erzwungen wird. Das TPM gibt keinen erratenen oder fremden Schlüssel preis; es gibt den regulären BitLocker-Schlüssel in einem Zustand frei, den Windows fälschlich nicht als Manipulation 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 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 wie bereits dargestellt 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

Damit es nicht zu Verwechslungen kommt, ist die Unterscheidung wichtig:

• Die im Kontext dieses Bypasses wünschenswerte BitLocker-Start-PIN, oft auch TPM-PIN genannt, wird vor dem Windows-Start abgefragt. Sie ist weder auf typischen Privatgeräten noch auf vielen Business-Geräten der Standard, weil Unternehmen häufig den komfortableren TPM-only-Betrieb nutzen und zusätzliche Pre-Boot-Eingaben aus Support- und Rollout-Gründen vermeiden. 
• Die Windows-Hello-PIN, die fast jedem User geläufig ist, gehört hingegen zur Windows-Anmeldung nach dem Start des Betriebssystems und ist in diesem Kontext irrelevant. Für den frühen BitLocker-Schutz ist sie nicht maßgeblich, weil das Systemlaufwerk in einer TPM-only-Konfiguration zu diesem Zeitpunkt in der Regel bereits automatisch entsperrt wurde.

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.

BitLocker mit TPM + Start-PIN einrichten und ausrollen

1. Voraussetzungen prüfen: BitLocker muss auf dem Betriebssystemlaufwerk aktiv oder für die Aktivierung vorbereitet sein. Das Gerät benötigt ein TPM, idealerweise TPM 2.0, und eine stabile UEFI-/Firmware-Konfiguration. Vor jeder Änderung muss der BitLocker-Wiederherstellungsschlüssel zuverlässig gesichert sein, zum Beispiel in Microsoft Entra ID, Active Directory, Intune oder einem anderen zentralen Schlüsselarchiv. Ohne bestätigten Recovery-Key sollte keine BitLocker-Start-PIN ausgerollt werden.
2. Gruppenrichtlinie aktivieren: Pfad:
   • Computerkonfiguration > Administrative Vorlagen > Windows-Komponenten > BitLocker-Laufwerkverschlüsselung > Betriebssystemlaufwerke > Zusätzliche Authentifizierung beim Start anfordern
   • Richtlinie aktivieren.
   • Für TPM-Geräte konfigurieren: TPM-Start-PIN erforderlich beziehungsweise sinngemäß: Require startup PIN with TPM
3. TPM+PIN-Protector auf einem Gerät hinzufügen. Administrative Eingabeaufforderung öffnen und ausführen:
   • manage-bde -protectors -add C: -TPMAndPIN
   • Danach die gewünschte BitLocker-Start-PIN eingeben.
   • Status prüfen:
     • manage-bde -protectors -get C:
     • manage-bde -status C:
4. In der Protector-Liste sollte anschließend ein Eintrag für TPM + PIN beziehungsweise TPMAndPIN erscheinen.
   • Gerät neu starten.
   • Vor dem Windows-Start muss nun die BitLocker-Start-PIN abgefragt werden.
5. Erst nach erfolgreicher Eingabe setzt BitLocker den Startvorgang fort und das Systemlaufwerk wird entsperrt.
6. Pilotgruppe verwenden: Nicht sofort flächendeckend ausrollen.
   • Zuerst eine kleine Pilotgruppe testen:
   • unterschiedliche Notebook-Modelle
   • unterschiedliche Firmware-Versionen
   • Geräte mit und ohne Dockingstation
   • Geräte mit aktiviertem Secure Boot
   • Geräte mit typischen BIOS-/UEFI-Updateprozessen
   • Geräte aus Homeoffice- und Außendienstszenarien
   • Dabei prüfen:
     • Start mit PIN funktioniert zuverlässig
     • Recovery-Key ist abrufbar
     • Helpdesk kann Recovery-Fälle bearbeiten
     • Firmware-Updates lösen keine unkontrollierbaren Sperren aus
     • Benutzer verstehen den Unterschied zwischen BitLocker-Start-PIN und Windows-Hello-PIN
7. Intune-/MDM-Rollout beachten
   • In Intune liegen die Einstellungen typischerweise unter:
     • Endpoint security > Disk encryption > BitLocker
     • oder in entsprechenden BitLocker-/Endpoint-Protection-Profilen.
     • Relevante Einstellungen sinngemäß:
       • Startup authentication required: Yes
       • Configure TPM startup PIN: Require startup PIN with TPM
       • Configure TPM startup key: Do not allow
       • Configure TPM startup key and PIN: Do not allow
       • Configure TPM startup: Allow oder Require TPM
8. Wichtig: Eine BitLocker-Start-PIN erfordert Benutzerinteraktion oder ein kontrolliertes Provisioning. Vollständig stille BitLocker-Aktivierung und verpflichtende Pre-Boot-PIN passen organisatorisch nicht immer zusammen.

Geräte ohne bestätigten Recovery-Key, Geräte mit problematischer Firmware oder Geräte ohne erreichbaren Supportprozess gehören nicht in die erste Rollout-Welle.

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.