YellowKey & BitUnlocker: Analyse der Windows-BitLocker-Umgehungs-schwachstelle, die wie eine Hintertür aussieht
YellowKey und BitUnlocker: Zwei unabhängige Entdeckungen derselben Schwachstellenklasse — die Auto-Unlock-Vertrauensgrenze von WinRE wird ausgenutzt, um die BitLocker-Vollverschlüsselung zu umgehen. Eine wurde von einem externen Forscher entdeckt, der sie eine Hintertür nennt; die andere wurde von Microsofts eigenem STORM-Team gefunden und als vier CVEs gepatcht.
Die Zwei Seiten Derselben Medaille
Innerhalb von weniger als einem Jahr kamen zwei Teams, die aus völlig unterschiedlichen Richtungen kamen, zu derselben erschreckenden Schlussfolgerung: Der standardmäßige TPM-only-Schutz von BitLocker kann über die Windows-Wiederherstellungsumgebung (WinRE) stillschweigend umgangen werden, sodass jeder mit physischem Zugriff vollständigen Befehlszeilenzugriff auf ein „verschlüsseltes” Laufwerk erhält.
| Aspekt | BitUnlocker (Microsoft STORM) | YellowKey (Nightmare-Eclipse) |
|---|---|---|
| Entdecker | Microsoft STORM-Team | Unabhängiger Forscher Nightmare-Eclipse |
| Offengelegt | Black Hat USA 2025 / DEF CON 33 (August 2025) | GitHub / öffentliche Offenlegung (Mai 2026) |
| Gepatcht | Juli 2025 Patch Tuesday (4 CVEs) | Zum Zeitpunkt des Schreibens kein Patch |
| Angriffsvektor | Mehrschrittige BCD + PBR-Manipulation | Einzelner USB, CTRL-Taste während WinRE-Start |
| Betroffene Versionen | Windows 10/11 + Server | Nur Windows 11 + Server 2022/2025 |
Das Beunruhigende: Keine erfordert das Knacken von AES. Keine erfordert das Erzwingen des Wiederherstellungsschlüssels. Beide gehen einfach durch eine Tür, die offen gelassen wurde.
BitUnlocker: Microsoft Findet Seine Eigenen Fehler
Microsofts STORM-Team präsentierte BitUnlocker auf der Black Hat USA 2025 und der DEF CON 33. Es enthüllte vier verschiedene Angriffsvektoren in WinRE, die alle mit dem Patch Tuesday Juli 2025 gepatcht wurden:
CVE-2025-48804: SDI-Dateiinjektion
Der Startprozess von WinRE verwendet eine Boot.sdi-Datei (System Deployment Image). Forscher fanden heraus, dass sie ein bösartiges Windows-Image an die legitime Boot.sdi anhängen konnten. Da WinRE das WIM nach dem SDI-Header nicht richtig validiert, startet das nicht vertrauenswürdige Image als ob es vertrauenswürdig wäre und erbt die Auto-Unlock-Privilegien von WinRE für BitLocker-Volumes.
CVE-2025-48800: Missbrauch von tttracer.exe
Der geplante Offline-Scan-Vorgang von WinRE führt Virenscans auf verschlüsselten Volumes durch. Das Dienstprogramm tttracer.exe (Time Travel Debugger), eine legitime, von Microsoft signierte Binärdatei, kann verwendet werden, um cmd.exe stellvertretend auszuführen, ohne den BitLocker-Sperrmechanismus auszulösen. Die Eingabeaufforderung erbt die speziellen Berechtigungen von WinRE für den Zugriff auf verschlüsselte Volumes.
CVE-2025-48003: SetupPlatform.exe-Hotkey
SetupPlatform.exe — eine Komponente, die nach Windows-Upgrades im vertrauenswürdigen Anwendungsregister verbleibt — registriert einen Shift+F10-Hotkey, der eine Eingabeaufforderung startet. Entscheidend ist, dass dies keine erneute Sperrung von BitLocker-Volumes auslöst. Ein Angreifer, der die ReAgent.xml-Konfiguration von WinRE beeinflussen kann, kann dies für dauerhaften Zugriff ausnutzen.
CVE-2025-48818: Vollständige Entschlüsselung über PBR
Das Kronjuwel. Durch Manipulation der BCD-Speicher (Boot Configuration Data) können Angreifer den Push-Button-Reset (PBR)-Ablauf von WinRE umleiten. Die Datei ResetSession.xml enthält eine DecryptVolume-Direktive. Indem der Angreifer einen bösartigen BCD-Speicher auf dem ungeschützten Wiederherstellungsvolume platziert, täuscht er PBR vor, das BitLocker-geschützte Betriebssystemvolume vollständig zu entschlüsseln.
Allen vier CVEs wurde ein CVSS v3.1-Score von 6,8 (Mittel) zugewiesen — aufgrund der Notwendigkeit physischen Zugriffs. Aber wie jeder Sicherheitsexperte weiß, ist „physischer Zugriff erforderlich” ein schwacher Trost, wenn ein Laptop in einem Café gestohlen wird.
YellowKey: Derjenige, Der Das Internet Zerbrach
Im Mai 2026 veröffentlichte der Forscher Nightmare-Eclipse YellowKey auf GitHub mit einer Beschreibung, die sofort viral ging:
„Eine der verrücktesten Entdeckungen, die ich je gemacht habe, fühlt sich fast an wie eine Hintertür, aber was weiß ich schon, vielleicht bin ich einfach nur verrückt.”
Der Exploit in 5 Schritten
- Erstelle einen Ordner
FsTxauf einem USB-Stick unterUSB:\System Volume Information\FsTx - Stecke den USB in einen BitLocker-geschützten Windows 11-Rechner
- Halte die SHIFT-Taste gedrückt und klicke auf Neustart (startet in WinRE)
- Beim Neustart des Systems SHIFT loslassen und CTRL gedrückt halten
- Eine Eingabeaufforderung erscheint mit vollem, uneingeschränktem Zugriff auf das BitLocker-verschlüsselte Volume
Das ist alles. Keine komplexe Nutzlast. Kein Knacken von Kryptographie. Kein Wiederherstellungsschlüssel. Nur ein USB-Stick und das richtige Timing von Tastendrücken.
Warum Es Funktioniert
Die für dieses Verhalten verantwortliche Komponente existiert nur in WinRE-Images. Sie prüft ein Flag namens FailRelock in einer Konfigurationsdatei (RecoverySimulation.ini). Wenn es gesetzt ist, sperrt WinRE das BitLocker-Laufwerk nach dem Entsperren während des Wiederherstellungsprozesses einfach nie wieder.
Die RecoverySimulation.ini-Datei auf dem USB löst den „Testmodus” für die Wiederherstellungstools von WinRE aus:
[Simulation]
Active=Yes
FailRelock=1Sobald der Testmodus aktiv ist, erbt cmd.exe von WinRE den entsperrten Zustand — und liest und schreibt auf das verschlüsselte Volume, als ob BitLocker nicht existierte.
Nightmare-Eclipse demonstrierte, dass dies Windows 11 und Server 2022/2025 betrifft, aber nicht Windows 10, was darauf hindeutet, dass der anfällige Code in der mit Windows 11 ausgelieferten WinRE-Version eingeführt wurde.
Hintertür Oder Bug? Die Beweise
Was YellowKey besonders beunruhigend macht, ist das Beweismuster, das auf Absicht hindeutet:
| Beobachtung | Implikation |
|---|---|
Das FailRelock-Debug-Flag existiert nur in WinRE, nicht in der normalen Windows-Komponente mit demselben Dateinamen | Eine bewusste Testeinrichtung wurde in die Produktion ausgeliefert |
| Derselbe Binärname existiert in normalem Windows ohne die Umgehungsfunktionalität | Dies ist kein allgemeiner Debug-Überrest — es wurde speziell in WinRE platziert |
| Nur Windows 11+ betroffen (Windows 10 nicht) | Der Code wurde im neuen WinRE-Image für Windows 11 eingeführt |
| Keine Dokumentation, kein Konfigurationstool, kein öffentlicher Verweis | Standard-Debug/Test-Flags werden normalerweise intern dokumentiert — dieses scheint absichtlich versteckt worden zu sein |
The Register zitierte Sicherheitsexperten, die sagten, es sei „unmöglich zu überprüfen”, ob es sich aufgrund der verfügbaren Informationen um eine absichtliche Hintertür handelt. Aber die Indizien sind zumindest verdächtig genug, um eine detaillierte Erklärung von Microsoft zu verlangen.
Vergleich: YellowKey vs BitUnlocker
| Dimension | BitUnlocker | YellowKey |
|---|---|---|
| Technische Komplexität | Hoch — mehrschrittige BCD-, PBR- und XML-Manipulation | Niedrig — einfacher USB + Tastenkombination |
| Ausführungszeit | ~10-30 Minuten | ~2 Minuten |
| Persistenz | Kann das Volume dauerhaft entschlüsseln | Nur sitzungsbasierter Zugriff |
| CVE | CVE-2025-48800, 48003, 48804, 48818 | Kein CVE zugewiesen |
| Patch-Status | Korrigiert Juli 2025 | Ungepatcht |
| Windows 10 betroffen | Ja | Nein |
| Hintertür-Verdacht | Nein (standardmäßige Schwachstellenoffenlegung) | Ja (Forscher behauptet Absicht) |
Die beiden ergänzen sich: BitUnlocker zeigt, dass sogar Microsofts eigenes Sicherheitsteam systemische Vertrauensprobleme in WinRE fand, während YellowKey darauf hindeutet, dass das Problem schlimmer sein könnte, als irgendjemand dachte — vielleicht absichtlich.
Warum Nur TPM Nicht Ausreicht
Die Standardkonfiguration von BitLocker auf modernen Windows-Geräten verwendet TPM-only-Schutz. Das TPM validiert die Startintegrität (PCR-Register) und gibt den Verschlüsselungsschlüssel automatisch frei, wenn das System normal startet. Dies bietet nahtlose Benutzererfahrung — kein Eingeben von Passwörtern bei jedem Start.
Aber es bedeutet auch: Jeder, der das Gerät starten kann, kann den Schlüssel erhalten.
| Schutzmodus | Widerstandsfähigkeit gegen YellowKey | Benutzererfahrung |
|---|---|---|
| Nur TPM | Gebrochen | Beste (kein Passwort) |
| TPM + PIN | Widerstandsfähig | Gut (PIN beim Start) |
| TPM + USB-Schlüssel | Widerstandsfähig | Schlecht (benötigt USB) |
| Nur Passwort | Widerstandsfähig | Schlecht (Passwort bei jedem Start) |
| Wiederherstellungsschlüssel | Nicht zutreffend | Nur für Notfälle |
Der YellowKey-Exploit funktioniert, weil TPM-only-Auto-Unlock WinRE implizit vertraut. Wenn Sie eine PIN hinzufügen, gibt das TPM den Schlüssel nicht ohne die PIN frei — selbst in WinRE. Dies unterbricht die Angriffskette.
Verteidigung in der Tiefe: Minderungsstrategien
Sofort (Kein Neustart Erforderlich)
Speziell für YellowKey, bis Microsoft einen Patch veröffentlicht:
- TPM + PIN-Schutz aktivieren — Führe
manage-bde -protectors -add C: -TPMAndPINin einer erhöhten Eingabeaufforderung aus - BIOS/UEFI-Passwort festlegen — Verhindert Manipulation der Startgeräteauswahl
- Externen Start deaktivieren — Konfiguriere UEFI so, dass nur von internen Speichern gestartet wird
- WinRE deaktivieren — (Nicht für die Produktion empfohlen, aber als letztes Mittel)
reagentc /disable
Langfristig (Organisationsrichtlinie)
| Kontrolle | Implementierung |
|---|---|
| BitLocker-Gruppenrichtlinie | Erzwinge Zusätzliche Authentifizierung beim Start erforderlich → TPM-Start-PIN konfigurieren: Start-PIN mit TPM erforderlich |
| Secure Boot + DBX | Stelle sicher, dass Secure Boot mit der neuesten Widerrufsliste (dbx) aktiviert ist |
| Windows Defender System Guard | Aktiviere System Guard Secure Launch (SMM-Schutz) |
| WinRE aktualisieren | Wende die neuesten WinRE-Wartungsstapelupdates an (KB5034231 und höher) |
| BitLocker-Netzwerkentsperrung | Verwende für domänenverbundene Desktops die Netzwerkentsperrung, um TPM-only-Fallstricke zu vermeiden |
Erkennung
Es gibt keine zuverlässige protokollbasierte Erkennung für YellowKey, da der Exploit vollständig innerhalb von WinRE arbeitet, bevor das Betriebssystem startet. Jedoch:
- Überwachung des Pre-Boot-Verhaltens: Geräte, die unerwartet in WinRE starten, sollten eine Untersuchung auslösen
- Audits des physischen Zugriffs: Verfolge Geräte, die außer Sichtweite waren
- USB-Startprotokolle: Die UEFI-Firmware kann Startgeräteauswahlen protokollieren
Was Dies Für Das BitLocker-Bedrohungsmodell Bedeutet
Das traditionelle Bedrohungsmodell für BitLocker war:
Angreifer mit physischem Zugriff: Geschützt, es sei denn, sie haben den Wiederherstellungsschlüssel oder können TPM + PIN erzwingen.
Das aktualisierte Bedrohungsmodell nach YellowKey:
Angreifer mit physischem Zugriff auf Windows 11+: Vollständige Kompromittierung in ~2 Minuten mit einem USB-Stick und einer gedrückten Taste.
Dies ist ein Paradigmenwechsel. Es bedeutet:
- TPM-only-BitLocker auf Windows 11 ist gegen einen entschlossenen physischen Angreifer praktisch dekorativ
- Laptop-Diebstahl kommt jetzt einem Datenverstoß gleich, es sei denn, TPM+PIN oder stärkere Schutzmaßnahmen sind aktiviert
- Unternehmenseinsätze, die auf die Standard-BitLocker-Konfiguration angewiesen sind, sind exponiert — die Ära des „Ankreuzens und Vergessens” ist vorbei
Der beunruhigendste Teil ist die Asymmetrie: Der Angreifer braucht nur einen USB-Stick und zwei Minuten physischen Zugriff. Der Verteidiger muss Richtlinienänderungen einführen, Benutzer schulen und sicherstellen, dass jedes Gerät TPM+PIN aktiviert hat.
Offenlegungszeitplan
| Datum | Ereignis |
|---|---|
| 2024-2025 | Microsofts STORM-Team erforscht WinRE-Angriffsflächen |
| 2025-07 | Microsoft patcht BitUnlocker-CVEs im Juli-Patch-Tuesday |
| 2025-08 | STORM präsentiert BitUnlocker auf der Black Hat USA und DEF CON 33 |
| 2026-05-12 | Nightmare-Eclipse veröffentlicht YellowKey auf GitHub |
| 2026-05-13 | The Register bestätigt YellowKey mit Sicherheitsexperten |
| 2026-05-13 | Community Reverse Engineering bestätigt FailRelock-Debug-Flag-Mechanismus |
| 2026-05-14 | Dieser Artikel veröffentlicht — kein offizieller Patch von Microsoft |
Das Größere Bild: Ein Muster von WinRE-Vertrauensfehlern
YellowKey ist kein isolierter Vorfall. Betrachtet man die breitere Landschaft:
| Schwachstelle | Jahr | Komponente | Auswirkung |
|---|---|---|---|
| CVE-2024-20666 | 2024 | Secure Boot / BitLocker | Umgehung der Sicherheitsfunktion |
| CVE-2025-48800 | 2025 | WinRE / tttracer | BitLocker-Umgehung via Offline-Scan |
| CVE-2025-48003 | 2025 | WinRE / SetupPlatform | BitLocker-Umgehung via Hotkey |
| CVE-2025-48804 | 2025 | WinRE / Boot.sdi | Umgehung der Startüberprüfung |
| CVE-2025-48818 | 2025 | WinRE / PBR | Vollständige Entschlüsselung des BitLocker-Volumes |
| YellowKey | 2026 | WinRE / FsTx-Debug-Flag | Ein-Tasten-BitLocker-Umgehung |
Die WinRE/WinPE-Angriffsfläche hat sich wiederholt als das schwächste Glied in der BitLocker-Kette erwiesen. Microsofts architektonische Entscheidung, WinRE für Auto-Unlock implizit zu vertrauen — ohne kryptografische Bestätigung dessen, was WinRE tut — schafft eine grundlegende Designspannung: Wie erlaubt man Wiederherstellung, ohne Missbrauch der Wiederherstellung zu erlauben?
Bisher ist jede Antwort gescheitert.
Fazit
YellowKey und BitUnlocker repräsentieren dasselbe grundlegende Problem: Der privilegierte Zugriff von WinRE auf BitLocker-Volumes kann durch Software-Richtlinien allein nicht angemessen gesichert werden, wenn ein Angreifer mit physischem Zugriff die Wiederherstellungsumgebung selbst manipulieren kann.
Wenn Sie in Ihrer Organisation für Windows-Sicherheit verantwortlich sind:
Auditieren Sie noch heute Ihre BitLocker-Konfiguration. Wenn TPM+PIN nicht erzwungen wird, gehen Sie davon aus, dass Ihre verschlüsselten Daten für jeden mit einem Schraubenzieher und einem USB-Stick zugänglich sind.
Schulen Sie Ihre Benutzer. Ein gestohlener Laptop ist nicht länger nur ein Hardwareverlust — mit YellowKey ist es ein garantierter Datenverstoß, wenn nur TPM verwendet wird.
Beobachten Sie Microsofts Reaktion. Wenn der Patch Tuesday vergeht, ohne YellowKey zu adressieren, wird die „Hintertür”-Theorie erheblich schwerer von der Hand zu weisen sein.
Referenzen
- YellowKey GitHub-Repository: https://github.com/Nightmare-Eclipse/YellowKey
- The Register-Berichterstattung: https://www.theregister.com/2026/05/13/disgruntled-researcher-releases-two-more-microsoft-zero-days/
- Microsoft BitUnlocker-Blog: https://techcommunity.microsoft.com/blog/microsoft-security-blog/bitunlocker-leveraging-windows-recovery-to-extract-bitlocker-secrets/4442806
- CVE-2025-48800 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48800
- CVE-2025-48003 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48003
- CVE-2025-48804 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48804
- CVE-2025-48818 (MSRC): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48818
- Saltt Tech Analyse: https://www.saltt.tech/insights/bitunlocker-a-deep-technical-analysis-of-a-full-volume-encryption-bypass
Infografik
Abbildung 1: YellowKey-Exploit-Ablauf — USB-Einstecken → WinRE-Start → CTRL gedrückt → uneingeschränkte Shell auf verschlüsseltem Volume