Sicherheitsforscher veröffentlicht Exploit und behauptet, Microsoft habe eine BitLocker-Hintertür eingebaut

• Der Sicherheitsforscher Nightmare-Eclipse hat YellowKey veröffentlicht und erklärt, dass sich die vollständige Volume-Verschlüsselung von BitLocker ohne Passwort umgehen lässt
• YellowKey lässt sich reproduzieren, indem der Ordner FsTx auf ein USB-Laufwerk mit einem Windows-kompatiblen Dateisystem kopiert wird und anschließend in WinRE eine bestimmte Abfolge durchgeführt wird
• Nach Abschluss des Verfahrens öffnet sich eine Befehls-Shell, über die sich BitLocker-geschützte Volumes durchsuchen, kopieren und anderweitige Dateioperationen ausführen lassen sollen
• Nightmare-Eclipse führt an, dass das Umgehungsverhalten nur in offiziellen WinRE-Images auftrete, und wirft daher die Möglichkeit einer absichtlich eingebauten Hintertür auf
• Als betroffen werden Windows 11, Server 2022, Server 2025 genannt; Windows 10 sei nicht betroffen

---

Bedingungen für die Funktionsweise von YellowKey

• Der Sicherheitsforscher Nightmare-Eclipse hat YellowKey veröffentlicht und erklärt, dass sich die vollständige Volume-Verschlüsselung von BitLocker vollständig umgehen lässt
• YellowKey lässt sich reproduzieren, indem der beigefügte FsTx-Ordner auf ein USB-Laufwerk kopiert wird, das mit einem Windows-kompatiblen Dateisystem wie NTFS, FAT32 oder exFAT formatiert ist
• Auch ohne USB-Laufwerk soll es funktionieren, wenn die FsTx-Dateien in die Windows-EFI-Partition kopiert und die verschlüsselte Festplatte vorübergehend aus dem System entfernt wird
• Anschließend muss das mit BitLocker geschützte System neu gestartet und die Windows Recovery Environment (WinRE) aufgerufen werden; danach ist eine bestimmte Eingabesequenz erforderlich
• Wenn das Verfahren korrekt abgeschlossen wird, erscheint eine Befehls-Shell, über die sich BitLocker-geschützte Volumes ohne Passwort durchsuchen, kopieren oder für andere Dateioperationen nutzen lassen sollen

Grundlage für den Verdacht einer Hintertür

• Nightmare-Eclipse hält YellowKey für ungewöhnlich genug, dass es sich nicht wie ein bislang unbekannter Sicherheitsfehler verhalte, und stellt die Möglichkeit in den Raum, dass Microsoft eine legitime Hintertür in das BitLocker-Datenschutzsystem eingebaut haben könnte
• Als Beleg wird angeführt, dass die problemverursachende Komponente nur in offiziellen WinRE-Images zu finden sei
• Dieselbe Komponente existiere zwar auch in Standard-Windows-Installationsabbildern, das auf realen Systemen beobachtete BitLocker-Umgehungsverhalten trete dort jedoch nicht auf
• Nightmare-Eclipse erklärte, ihm falle „keine andere Erklärung ein als die Tatsache, dass dies absichtlich war“, und fügte hinzu, dass Windows 10 nicht betroffen sei, sondern nur Windows 11, Server 2022, Server 2025

Externe Bestätigung und weitere Veröffentlichung

• Berichten zufolge haben Drittanbieter-Forscher bestätigt, dass YellowKey wie in den GitHub-Unterlagen von Nightmare-Eclipse beschrieben funktioniert
• Nightmare-Eclipse hat außerdem einen zweiten Exploit namens GreenPlasma veröffentlicht, mit dem sich laut Beschreibung eine Rechteausweitung erreichen lässt
• Für GreenPlasma wurde kein vollständiger Proof-of-Concept-Code veröffentlicht, der SYSTEM-Level-Zugriff erreicht; weitere Details könnten laut Andeutung vor dem nächsten Patch Tuesday folgen

Mögliche Gegenmaßnahmen

• Als Gegenmaßnahme gegen das vermutete Hintertür-Verhalten von YellowKey wird ein vergleichsweise einfacher Ansatz genannt
• Sicherheitsexperten empfehlen, sich nicht allein auf ein einzelnes Verschlüsselungssystem zu verlassen, sondern auch gut geprüfte Alternativen für vollständige Festplattenverschlüsselung zu evaluieren
• Als Beispiel wird VeraCrypt genannt

[GN⁺]

Hacker-News-Kommentare

• Wenn man sich den Beitrag des Forschers Nightmare-Eclipse ansieht, der diese Schwachstelle gefunden hat, scheint sich das schon seit fast einer Woche anzubahnen.
  Am Dienstag, dem 12. Mai 2026, schrieb er: „Diesmal sind es zwei Schwachstellen [YellowKey] [GreenPlasma] [...] Am nächsten Patch Tuesday wird Microsoft eine große Überraschung erleben“, und am Mittwoch, dem 13. Mai: „Wenn ich die ganze Geschichte offenlegen kann, werden die Leute sehen, dass mein Ausraster ziemlich nachvollziehbar war, und für Microsoft wird das absolut nicht gut aussehen.“
  Blog des Autors: https://deadeclipse666.blogspot.com/
  Im ersten Beitrag vom März 2026 steht sinngemäß: „Jemand hat unsere Vereinbarung gebrochen, und ich bin mittellos geworden und habe sogar mein Zuhause verloren. Sie haben mir in den Rücken gefallen, obwohl sie wussten, dass das passieren würde. Das ist nicht meine Entscheidung, sondern ihre.“
  Ich weiß nicht genau, wie man das einordnen soll, aber es klingt fast wie ein faktisches „Leaken“ durch einen Insider, und andere scheinen die Ergebnisse ebenfalls reproduzieren zu können.

  • Es liest sich für mich weniger wie ein Insider als eher so, dass er mit Microsoft im Verfahren zur Offenlegung von Schwachstellen war, aus irgendeinem Grund wütend wurde und es dann veröffentlicht hat.
  • Das wurde auf HN bereits mehrfach diskutiert, zum Beispiel hier: https://news.ycombinator.com/item?id=48130519
    Ob das eine Backdoor ist oder nicht, hängt letztlich davon ab, wie man sonst üblicherweise „Bug oder Backdoor?“ bewertet, und es ist nicht die simple Geschichte à la „Microsoft gleich 1, BitLocker gehackt“, wie Technikmedien sie gerne hätten.
    Im Kern geht es um einen Bug in der Wiedergabe der NTFS-Transaktionslogs der Windows Recovery Environment WinRE, durch den NTFS-Transaktionslogs externer Volumes gelesen und auf das gemountete Dateisystem angewendet werden können. Dadurch kann ein Angreifer die WinRE-Authentifizierung umgehen.
    Bei BitLocker ohne PIN oder Passwort bedeutet jede Umgehung der Authentifizierung zugleich eine Umgehung der Festplattenverschlüsselung. Der Bootloader hat den Datenträger dann bereits entsiegelt, und dieser strukturelle „Mangel“ existiert in derselben Konfiguration auch unter Linux. Das gilt zum Beispiel auch, wenn man im Ubuntu-Installer die relativ neu hinzugefügte Checkbox für Hardware Disk Encryption verwendet.
    Ohne zusätzliche Belege hängt die Frage, ob das NTFS-Transaktionslog-Problem eine absichtlich eingebaute Backdoor oder nur ein banaler Enumerations-Bug ist, davon ab, wie stark man zu den in der Exploit-Entwicklung üblichen Verschwörungstheorien neigt. Für mich wirkt es wie ein plausibler Bug, und die Schwäche des Entsiegelns beim Booten ist bekannt und offensichtlich genug, dass ich das nicht als weltbewegende Enthüllung sehe, aber es ist ein interessanter Bug.
  • Ich möchte möglichst bald die Blogposts lesen, um zu verstehen, was genau passiert ist und warum diese Person M$ bloßstellen wollte.

• Bessere Zusammenfassung: https://infosec.exchange/@wdormann/116565129854382214
  Der veröffentlichte Exploit betrifft BitLocker mit PIN nicht. Ohne PIN ist BitLocker ohnehin nicht sicher.
  Der ursprüngliche Autor behauptet zwar, einen Exploit zu haben, der auch mit PIN funktioniert, hat dafür aber bisher keine Belege vorgelegt.

  • Verlangt eure Firma eine PIN? Noch wichtiger: Verlangt der Cyberversicherer, den eure Firma bezahlt, eine PIN?
    Ich habe noch kein Unternehmen gesehen, das für BitLocker eine PIN verlangt.
  • Bei BitLocker gibt es noch eine Stufe über der PIN: Man kann einen USB-Stick mit einem Schlüssel verwenden, der nur beim Booten gebraucht wird. Da die Daten nicht auf dem Gerät gespeichert sind, sollte das gegen diesen Angriff sicher sein.
  • Wenn man annimmt, dass die Behauptung zur PIN-Version stimmt, ist es interessant, warum statt dieser PIN-Version die abgeschwächte, nutzlose Version veröffentlicht wurde. Ich habe ein paar Gedanken dazu, aber keinerlei Belege.

• Quelle: https://infosec.exchange/@wdormann/116565129854382214
  „Eine typische WinRE-Sitzung hat das Verzeichnis X:\Windows\System32, und darin befindet sich die Datei winpeshl.ini.“
  „Beim YellowKey-Exploit scheint es jedoch so zu sein, dass Transactional-NTFS-Fragmente vom USB-Laufwerk die Datei winpeshl.ini auf einem anderen Laufwerk löschen können.“
  Interessant. Ich kenne diese Umgebung nicht gut, aber ist das naiv betrachtet ein Problem beim Erstellen oder Weiterreichen von Dateihandles? Wenn ja, warum wäre dann während des WinRE-Neustarts eine Tastatureingabe nötig?
  Ich frage mich auch, wie gut sich das patchen lässt. Unzählige WinRE-USB-Laufwerke werden sich ja nicht anfassen lassen — könnte man die Zugriffsrechte auf der BitLocker-Seite aktualisieren? Wäre Entschlüsselung/Neuverschlüsselung nötig? Es scheint, als käme dazu noch einiges.

  • Der fehlende Teil ist, warum WinRE überhaupt die nötigen Rechte hat. Windows speichert den Entschlüsselungsschlüssel im TPM, sodass WinRE den Datenträger auch ohne Recovery Key entschlüsseln kann.
    Deshalb braucht dieser Angriff WinRE und nicht einfach einen Boot mit etwas wie einer Ubuntu-Live-CD.
    Außerdem muss man nicht alle vorhandenen WinRE-USB-Laufwerke patchen. Wenn man die Secure-Boot-Signatur widerruft, besteht sie die TPM-Prüfung nicht mehr und kann deshalb keinen Datenträger mehr entschlüsseln.

• „Sicherheitsexperten raten allgemein dazu, sich nicht auf ein einzelnes Verschlüsselungssystem zu verlassen und gut geprüfte Alternativen zur vollständigen Festplattenverschlüsselung wie VeraCrypt zu evaluieren.“
  Wenn man tatsächlich eine Backdoor in FDE eingebaut hätte, wäre es sinnvoller, den Leuten gleich zu sagen, sie sollten Windows ganz aufgeben und Linux verwenden.
  Wenn in FDE eine Backdoor steckt, muss man davon ausgehen, dass es im Betriebssystem selbst nicht nur eine einzige Backdoor geben wird. Proprietärer Software sollte man überhaupt nicht vertrauen, und schlecht auditierter Open-Source-Software ebenso wenig.

  • Ich nutze Microsoft-Produkte größtenteils nicht, aber selbst auf deinem Rechner würde ich VeraCrypt nicht einsetzen.
  • Oder man verwendet etwas Open-Source-basiertes wie VeraCrypt.

• Das wirkt weniger wie ein reines BitLocker-Problem als eher wie ein Login-Bypass. Wenn man sich ohne PIN auf das TPM verlässt, wird automatisch entschlüsselt.
  Normalerweise sollte das okay sein, weil ein Angreifer den Login-Screen trotzdem nicht überwinden kann, aber dieser Exploit scheint zu zeigen, wie man in der Recovery-Umgebung eine uneingeschränkte Shell erhält.
  Der Forscher behauptet, auch eine Methode zum Umgehen der PIN zu haben, hat sie aber noch nicht veröffentlicht.

  • Wenn im Offenlegungsprozess keine Belohnung gezahlt wurde, könnte er entschieden haben, dass es besser ist, das an jemanden zu verkaufen, der dafür zahlt.

• Ab wann werden Sicherheitsexperten wohl beginnen, Rollen im Bereich „Microsoft-Produktsicherheit“ abzulehnen? Ich bin an diesem Punkt schon angekommen.
  Microsoft-Produktsicherheit ist nur noch eine hektische Beschäftigung, bis sie unter der nächsten Welle von wahnsinnigem technischem Schuldenberg und Gier bei MS wieder zusammenbricht. Jetzt gibt es sogar Backdoors.

  • Das ist keine „Sicherheitsrolle“, sondern eine Compliance-Rolle. Genau das ist letztlich alles, was den meisten Unternehmenskunden wirklich wichtig ist.
    Sie erfüllen alle Compliance-Regeln und folgen den von MS beeinflussten „Best Practices“, damit, was auch immer passiert, am Ende nicht ihre Schuld ist.
  • iOS erstellt standardmäßig ebenfalls keine Ende-zu-Ende-verschlüsselten iCloud-Backups, sodass Strafverfolger Chats, Browserverlauf usw. anfordern können. Signal ist da eine bemerkenswerte Ausnahme.
    Man kann zwar ADP für Ende-zu-Ende-verschlüsselte Backups aktivieren, aber es hilft möglicherweise nicht viel, weil die Gesprächspartner es wahrscheinlich nicht aktiviert haben.
    Ich will Microsoft nicht verteidigen, sondern nur sagen, dass all diese Unternehmen Teil von PRISM waren.
  • Im Enterprise-Markt verdient man damit einfach zu viel Geld, als dass die Leute anfangen würden, Arbeit nur deshalb abzulehnen, weil sie lästig ist.
  • „Jetzt gibt es sogar Backdoors“? „Jetzt“?
    Sollen wir darüber reden, warum bei einer Version von Windows NT, die versehentlich mit aktivierten Debug-Symbolen ausgeliefert wurde, der Schlüssel, den Microsoft als „Reserve-Key“ bezeichnete, den Namen ..._NSAKEY trug?
    Genau ein einziges Mal wurde Windows mit aktivierten Debug-Symbolen ausgeliefert, und ausgerechnet da hieß ein Verschlüsselungsschlüssel „NSAKEY“.
    Natürlich werden Leute, die bei Fehlverhalten von Staaten weiterhin wegsehen, behaupten, das sei völlig normal, und die damals sorgfältig ausgearbeitete Microsoft-Ausrede „Das ist keine Backdoor“ einfach wiederholen.

• Ich habe den Exploit noch etwas weiter untersucht, und er zielt auf BitLocker im reinen TPM-Modus. Das heißt: keine Pre-Boot-Authentifizierung oder Ähnliches.
  Wenn Secure Boot die Boot-Kette verifiziert, gibt das TPM den Verschlüsselungsschlüssel von selbst heraus. Bei physischem Zugriff macht das keinen großen Unterschied.
  Man kann entweder mit einem USB-Stick mit dem Exploit booten und eine Notfall-Shell bekommen oder einen 5-Dollar-Mikrocontroller kaufen und ihn an bestimmte Pins auf dem Mainboard löten, um den TPM-Schlüssel mitzuschneiden.
  Microsoft verkauft etwas, das insgesamt nicht sicher ist, als vollständige Festplattenverschlüsselung. Wer einen Exploit auf einen USB-Stick packen, eine Shell erlangen und Dateien durchsuchen und kopieren kann, kann auch einen Mikrocontroller kaufen und einem YouTube-Lötvideo folgen.
  Deshalb ist nicht der „Exploit“ selbst das Problem, sondern das falsche Sicherheitsgefühl, das Microsoft verkauft.

  • Die Methode „mit einem bootfähigen Stick in eine Notfall-Shell gehen“ funktioniert so nicht. Das TPM gibt den Schlüssel nur frei, wenn in ein „autorisiertes“ Betriebssystem gebootet wird, konkret also wenn der PCR-Zustand, an den der Verschlüsselungsschlüssel gebunden ist, passt.
    Das Mitschneiden des TPM-Schlüssels mit einem 5-Dollar-Mikrocontroller durch Löten an bestimmte Pins ist nur bei dTPM möglich. fTPM ist dafür nicht anfällig und zudem deutlich weiter verbreitet als dTPM.
  • Ubuntu hat vor ein paar Versionen ebenfalls TPM-basierte FDE eingeführt. Schon damals hatte ich denselben Gedanken und habe mich entschieden, das nicht zu verwenden.
    Beim Booten ein Geheimnis einzugeben, ist ohnehin längst Muskelgedächtnis und bietet einfache, vertrauenswürdige Sicherheit.
    Man kann die Daten auch ohne Mainboard wiederherstellen.
    Für den Alltag könnte ein hybrides Setup sinnvoll sein, bei dem man einen Slot mit Secure Boot+TPM+Geheimnis zur Abwehr von Evil-Maid-Angriffen nutzt und zusätzlich einen Backup-Slot mit einem Geheimnis hat.
  • Es wird zwar auch ein TPM+PIN-Exploit behauptet, aber wie vertrauenswürdig das ist, muss man erst noch sehen.
    https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
  • Linux LUKS lässt sich exakt auf dieselbe Weise konfigurieren.
    Das wirkt weniger wie ein BitLocker-Angriff als eher wie ein Angriff auf die Secure-Boot-Kette.
    Der Nutzen von Entsperren ohne PIN besteht dann, wenn sich das Bedrohungsmodell auf Datenträgerentsorgung, Datenträgerausbau oder die Trennung von TPM und Datenträger beschränkt.
    Wenn mehrere Nutzer ein Gerät regelmäßig verwenden, kann die Eingabe einer PIN unpraktisch oder unmöglich sein. Dann verlagert man die Zugriffsprüfung auf vertrauenswürdige Betriebssystemkomponenten.
  • Es ist ein sehr schwerwiegender Bug, aber BitLocker ist dennoch vollständige Festplattenverschlüsselung. Es gibt nur eine Möglichkeit zur Umgehung der Authentifizierung.

• Erinnert sich noch jemand an die Formulierung „Die Verwendung von TrueCrypt ist nicht sicher und kann ungepatchte Sicherheitsprobleme enthalten“? ;)

  • Das erinnert an TrueCrypt/VeraCrypt. Das ist vermutlich eine sicherere Verschlüsselungslösung. Nach dieser Sache wirkt es definitiv sicherer.