BitLocker unter Beschuss: Das YellowKey-Problem
Microsofts BitLocker gilt als Goldstandard für die Verschlüsselung von Windows-Systemen. Doch die Sicherheitslücke CVE-2026-45585, öffentlich bekannt als YellowKey, reißt eine erhebliche Lücke in dieses Schutzschild. Mit einem CVSS-Score von 6.8 ist die Schwachstelle zwar nicht kritisch, aber die Auswirkungen sind es durchaus: Ein Angreifer mit physischem Zugriff kann die BitLocker Device Encryption komplett umgehen und auf die verschlüsselten Daten zugreifen.
Entdeckt wurde YellowKey vom Security-Researcher „Chaotic Eclipse“ (aka Nightmare-Eclipse). Dass der Proof of Concept (PoC) direkt öffentlich gemacht wurde, sorgte bei Microsoft für Kritik – es verstoße gegen die Best Practices einer koordinierten Offenlegung. Dennoch liegt der Ball nun bei den Administratoren.
Der technische Mechanismus von YellowKey
Die Schwachstelle ist ein klassischer Security Feature Bypass. Die Angriffskette ist erschreckend simpel: Ein Angreifer platziert speziell manipulierte FsTx-Dateien auf einem USB-Laufwerk oder einer EFI-Partition. Dieses Medium wird an den Zielrechner angeschlossen, der durch BitLocker geschützt ist. Bootet das System nun in die Windows Recovery Environment (WinRE) und hält der Angreifer die CTRL-Taste gedrückt, öffnet sich eine Shell mit uneingeschränktem Zugriff auf das eigentlich verschlüsselte Volume.
Betroffen sind moderne Systeme, darunter Windows 11 Versionen 24H2, 25H2 und 26H1 (jeweils x64) sowie Windows Server 2025 und die Server-Core-Variante. Technisch ausgenutzt wird hierbei der Transactional NTFS (TxF) Mechanismus. Wie Security-Researcher Will Dormann erläutert, löscht das automatische Abspielen des FsTx Auto Recovery Utility (autofstx.exe) beim Start von WinRE die Datei winpeshl.ini, was den Weg für die unautorisierte Shell ebnet.
Die Mitigation: Ein Albtraum für IT-Admins
Anstatt einen klassischen Patch über den regulären Update-Zyklus auszuliefern, hat Microsoft eine manuelle Mitigation veröffentlicht. Für Enterprise-Umgebungen ist das ein logistischer Albtraum. Die Anleitung umfasst mehrere tiefgreifende Schritte:
- Das WinRE-Image auf jedem Gerät muss gemountet werden.
- Die System-Registry-Hive des gemounteten WinRE-Images muss geladen werden.
- Der Wert
autofstx.exemuss aus demBootExecute REG_MULTI_SZ-Wert des Session Managers entfernt werden. - Die Registry-Hive muss gespeichert und entladen werden.
- Das WinRE-Image muss unmounted und committet werden.
- Der BitLocker-Trust für WinRE muss neu hergestellt werden.
Diesen Prozess auf Tausenden von Endgeräten manuell durchzuführen, ist kaum praktikabel. Zwar lassen sich diese Schritte theoretisch skripten, jedoch birgt das manuelle Editieren der WinRE-Registry und das anschließende Wiederherstellen des BitLocker-Trusts ein hohes Fehlerpotenzial. Ein fehlerhaftes WinRE-Image kann die Disaster-Recovery-Fähigkeiten eines Unternehmens massiv einschränken.
Die wahre Lösung: TPM+PIN statt TPM-only
Microsoft nennt in seinem Advisory noch eine zweite, weitaus praktikablere Schutzmaßnahme: Die Umstellung von „TPM-only“ auf „TPM+PIN“. Genau hier liegt der eigentliche Kern des Problems.
Die Standardkonfiguration von BitLocker setzt oft auf „TPM-only“. Das System bootet stillschweigend, sofern die Hardware-Integrität durch das Trusted Platform Module (TPM) bestätigt wird. Das ist bequem für Nutzer, öffnet aber bei physischem Zugriff – wie bei YellowKey – Tür und Tor. Ein Angreifer kann das System ungestört in WinRE booten, da keine interaktive Authentifizierung beim Start verlangt wird.
Wird hingegen „TPM+PIN“ erzwungen, muss der Nutzer vor dem Booten eine PIN eingeben. Ein Angreifer, der einen Laptop stiehlt oder kurz Zugriff auf ein unbeaufsichtigtes Gerät hat, kann das System nicht neu starten und somit auch die YellowKey-Angriffskette nicht auslösen.
Für noch nicht verschlüsselte Geräte empfiehlt Microsoft, über Intune oder Gruppenrichtlinien (GPO) die Option „Require additional authentication at startup“ zu aktivieren und „Configure TPM startup PIN“ auf „Require startup PIN with TPM“ zu setzen.
Fazit: Bequemlichkeit vs. Sicherheit
YellowKey zeigt einmal mehr den fundamentalen Konflikt zwischen Benutzerfreundlichkeit und Sicherheit. Die „TPM-only“-Konfiguration ist ein Zugeständnis an eine nahtlose Nutzererfahrung, die jedoch einen klassischen Evil-Maid-Angriff ermöglicht. Die manuelle Microsoft-Mitigation ist ein Strohhalm, der Administratoren viel Arbeit bescheren wird. Die einzig wahre, skalierbare Lösung besteht darin, die BitLocker-Richtlinien enterprise-weit auf „TPM+PIN“ umzustellen. Ja, das erfordert einen Kulturwechsel bei den Nutzern – aber es ist der einzige Weg, um physische Angriffe auf Windows-Volumes nachhaltig abzuwehren, bis Microsoft einen automatisierten Patch für die WinRE-Schwachstelle nachliefert.
Quelle: The Hacker News
