Mobile-Menu

CVE-2026-45585 knackt BitLocker über Windows-Wiederherstellungsmodul YellowKey-Exploit liest BitLocker-Volumes im Klartext aus

Von Thomas Joos 3 min Lesedauer

Anbieter zum Thema

cidaas by Widas ID GmbH
FAST LTA GmbH
SEPPmail - Deutschland GmbH

Der YellowKey-Exploit hebelt BitLocker über die Windows-Wiederherstel­lungs­umgebung aus und ermöglicht Klartext-Zugriff auf verschlüsselte Laufwerke mit USB-Stick und Neustart. Microsoft führt die Lücke unter CVE-2026-45585, ein Patch steht noch aus. Als sofortige Schutzmaßnahme empfiehlt Microsoft TPM+PIN sowie ein PowerShell-Skript zur Bereinigung des WinRE-Images.

YellowKey hebelt BitLocker über die Windows-Wiederherstellungsumgebung aus. TPM+PIN schützt sofort, ein Patch steht noch aus.(Bild: Gemini / KI-generiert)
YellowKey hebelt BitLocker über die Windows-Wiederherstellungsumgebung aus. TPM+PIN schützt sofort, ein Patch steht noch aus.
(Bild: Gemini / KI-generiert)

Microsoft dokumentiert die als YellowKey bekannte Sicherheitslücke unter CVE-2026-45585 und stellt eine Übergangsmaßnahme bereit. Ein anonymer Sicherheitsforscher unter dem Namen Nightmare Eclipse hat den Fehler offengelegt und einen Proof-of-Concept veröffentlicht, was die Regeln der koordinierten Offenlegung verletzt. Der gleiche Forscher publizierte zuvor weitere Windows-Schwachstellen, darunter die Rechteausweitung BlueHammer (CVE-2026-33825), die inzwischen aktiv ausgenutzt wird. Der Angriff setzt physischen Zugriff voraus und betrifft Windows 11 in den Versionen 24H2, 25H2 und 26H1 für x64 sowie Windows Server 2025 einschließlich der Server-Core-Installation.

Angriffsweg über das Wiederherstellungsmodul

Der Exploit nutzt präparierte FsTx-Dateien, die der Angreifer auf einem USB-Laufwerk oder in der EFI-Partition ablegt. Nach einem Neustart in die Windows-Wiederherstellungsumgebung (WinRE) und gedrückter STRG-Taste öffnet sich eine Shell mit uneingeschränktem Zugriff auf das BitLocker-geschützte Volume. Der Schutz der Laufwerksverschlüsselung greift in diesem Zustand nicht mehr, der Angreifer liest und schreibt Daten im Klartext. Eine Installation von Software, vorhandene Anmeldedaten oder Netzzugang sind nicht erforderlich, ein USB-Anschluss und die Möglichkeit zum Neustart genügen.

Verantwortlich ist die FsTx Auto Recovery Utility autofstx.exe. Nach Darstellung des Tharros-Analysten Will Dormann startet dieses Programm automatisch, sobald das WinRE-Image geladen wird, und stößt ein Transactional-NTFS-Replaying an, das die Datei winpeshl.ini entfernt und so den Übergang in die Shell ermöglicht. Ohne den automatischen Start unterbleibt diese Kette.

Einstufung und Risiko

Microsoft bewertet die Lücke als wichtig und vergibt einen CVSS-Score von 6,8. Der Vektor weist physischen Zugriff bei niedriger Komplexität aus, ohne benötigte Berechtigungen und ohne Benutzerinteraktion. Vertraulichkeit, Integrität und Verfügbarkeit stuft Microsoft jeweils als hoch ein. Die zugrunde liegende Schwäche ordnet das Unternehmen als Command Injection (CWE-77) ein. Der Proof-of-Concept ist öffentlich, eine aktive Ausnutzung beobachtet Microsoft bislang nicht, schätzt sie aber als wahrscheinlicher ein. An einem Sicherheitsupdate arbeitet der Hersteller, zum 22.05.2026 steht es noch nicht bereit.

Mitigation im Recovery-Image

Die empfohlene Maßnahme entfernt den Eintrag autofstx.exe aus dem Wert BootExecute des Session Managers in der WinRE-Registry. Microsoft stellt dafür seit dem 21.05.2026 ein PowerShell-Skript bereit und hat die zuvor manuellen Schritte ersetzt. Das Skript mountet das WinRE-Image über reagentc /mountre, lädt die Offline-Hive SYSTEM per reg load, liest den REG_MULTI_SZ-Wert BootExecute aus und streicht den Eintrag in jedem aktiven ControlSet. Danach entlädt es die Hive, schreibt das Image mit reagentc /unmountre /commit zurück und stellt über einen Zyklus aus reagentc /disable und reagentc /enable die BitLocker-Vertrauenskette für WinRE wieder her.

Microsoft gibt an, dass die Maßnahme die Service-Verfügbarkeit und den Verwaltungsbetrieb nicht beeinträchtigt. Nach dem Einspielen des späteren Sicherheitsupdates bleibt das geänderte Verhalten erhalten, eine Rücknahme der Anpassung ist nicht notwendig.

Schutz über TPM und PIN

Geräte mit TPM+PIN sind nach Angaben von Microsoft nicht angreifbar. Auf bereits verschlüsselten Systemen lässt sich BitLocker von der reinen TPM-Bindung auf TPM+PIN umstellen, über PowerShell, die Kommandozeile oder die Systemsteuerung. Die Verschlüsselung verlangt dann beim Start eine PIN und blockiert den YellowKey-Angriff. Für noch nicht verschlüsselte Geräte aktivieren Administratoren über Microsoft Intune oder Gruppenrichtlinien die Option "Require additional authentication at startup" und setzen "Configure TPM startup PIN" auf "Require startup PIN with TPM".

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Fazit

Die Schwachstelle liegt in der Vertrauenskette des Wiederherstellungsmoduls. WinRE gehört damit unter dieselbe Patch- und Integritätskontrolle, die für das produktive Windows-System gilt. TPM+PIN schließt die Lücke sofort, die skriptbasierte Bereinigung der WinRE-Registry hält bis zum Sicherheitsupdate.

(ID:50853114)

Weiterführende Inhalte