SEKurity GmbH Logo
Allgemein

BitLocker umgangen – warum ein gepatchtes Windows 11 nicht reicht

BitUnlocker und YellowKey zeigen, dass BitLocker-Bypasses nicht die Kryptografie brechen — sie nutzen die Vertrauenskette rund um WinRE, TPM und Secure Boot aus.

Alexander Sturz

Gründer & Red Team Lead

11 Min. Lesezeit
Teilen:

Executive Summary

Mitte 2025 stellte Microsofts STORM-Team mit BitUnlocker vier Schwachstellen vor, die zeigten, wie sich BitLocker über die Windows Recovery Environment (WinRE) umgehen lässt. Die Patches erschienen im Juli 2025, die öffentliche Vorstellung folgte auf der Black Hat USA und DEF CON 33 im August 2025. Im Mai 2026 folgte mit YellowKey (CVE-2026-45585) eine weitere Schwachstelle auf derselben Angriffsfläche.

Bemerkenswert ist dabei nicht die Existenz einzelner Schwachstellen. Bemerkenswert ist vielmehr, dass beide Veröffentlichungen auf derselben Designentscheidung aufbauen: Damit Windows repariert werden kann, muss BitLocker der Recovery-Umgebung vertrauen.

Wer verstehen möchte, warum ein vollständig gepatchtes Windows-System dennoch angreifbar sein kann, muss verstehen, wie TPM, PCRs, Secure Boot, WinRE und die Recovery-Partition zusammenspielen.

BitLocker schützt nicht die Festplatte

Viele Administratoren beschreiben BitLocker vereinfacht als Festplattenverschlüsselung.

Technisch betrachtet ist das nicht falsch, aber unvollständig.

Die eigentliche Sicherheitsfrage lautet nicht:

Sind die Daten verschlüsselt?

Sondern:

Unter welchen Bedingungen wird der Schlüssel freigegeben?

Das von BitLocker eingesetzte XTS-AES (standardmäßig mit 128 Bit, optional 256 Bit) zu brechen ist praktisch unmöglich, sofern kein trivialer Schlüssel verwendet wird. Deshalb greifen moderne Angriffe nicht die Kryptografie an, sondern den Mechanismus, der entscheidet, wann der Schlüssel verwendet werden darf.

Genau hier kommt das TPM ins Spiel.

TPM, PCRs und die eigentliche Vertrauenskette

Eine häufige Vereinfachung lautet:

Das TPM sichert den Schlüssel.

Technisch passiert etwas anderes.

Während des Startvorgangs messen Firmware- und Boot-Komponenten jeweils die nächste Komponente in der Boot-Kette. Die dabei entstehenden Hashwerte werden über sogenannte PCR-Extend-Operationen in die Platform Configuration Registers (PCRs) des TPM geschrieben.

Vereinfacht:

UEFI Firmware
      |
      |-- misst nächste Komponente
      |
      |-- berechnet Hash
      |
      +-- PCR Extend
               |
               v
          TPM PCR Register

Das TPM bewertet dabei nicht, ob etwas “sicher” oder “unsicher” ist.

Es speichert lediglich die Messwerte manipulationssicher.

Entscheidend ist, welche dieser Register BitLocker tatsächlich in seine Versiegelung einbezieht. Das Standardprofil moderner Windows-Installationen mit Secure Boot umfasst PCR 7 und PCR 11:

PCR7  -> Secure-Boot-Zustand
         (Richtlinien, Zertifikate)

PCR11 -> BitLocker-Zugriffssteuerung
         (Seal/Unseal-Zustandsmaschine)

PCR 11 ist dabei das eigentliche “Schloss”, gegen das BitLocker den Schlüssel versiegelt.

Daneben existiert ein erweitertes Profil, das zusätzlich frühe Boot-Komponenten misst:

PCR0  -> CRTM und Firmware-Messungen

PCR2  -> Option ROMs

PCR4  -> Boot Manager / Boot Loader

Diese drei Register sind standardmäßig nicht Teil der BitLocker-Policy. Das ist später für die Angriffe relevant: Wer PCR 0/2/4 wieder aufnimmt, lässt das TPM eine Veränderung der Firmware- und Boot-Manager-Kette bemerken — und genau das blockiert die weiter unten beschriebene Downgrade-Variante. Welche PCRs tatsächlich verwendet werden, hängt von Hardware, Firmware und Konfiguration ab.

Sealing und Unsealing: Was BitLocker tatsächlich macht

Beim Aktivieren von BitLocker wird der Volume Master Key nicht einfach auf der Platte abgelegt.

Stattdessen wird er gegen einen definierten PCR-Zustand versiegelt (sealed).

Vereinfacht:

Volume Master Key
        |
        v
TPM Seal Operation
        |
        v
Freigabe nur bei passenden PCR-Werten

Beim Systemstart versucht Windows anschließend, den Schlüssel wieder zu entsiegeln (unseal).

Sind die PCR-Werte identisch mit dem Zustand beim Sealing, wird der Schlüssel freigegeben.

Andernfalls erscheint die BitLocker-Recovery-Abfrage.

PCR-Werte stimmen
        |
        v
Unseal erfolgreich
        |
        v
Windows startet

PCR-Werte abweichend
        |
        v
Recovery Key erforderlich

Wichtig:

Das TPM prüft nicht, ob Windows kompromittiert wurde.

Es prüft lediglich, ob die gemessene Boot-Kette dem erwarteten Zustand entspricht.

Warum BitLocker WinRE vertrauen muss

An dieser Stelle beginnt das eigentliche Problem.

Windows besitzt mit WinRE eine Recovery-Umgebung für Reparaturen, Zurücksetzungen und Diagnosen.

Wenn Windows nicht mehr startet, soll WinRE trotzdem auf das verschlüsselte Betriebssystem zugreifen können.

Ohne diese Funktion wären viele Reparaturmaßnahmen unmöglich.

Microsoft musste deshalb eine Designentscheidung treffen:

Normaler Boot
    |
    v
Windows

Recovery Boot
    |
    v
WinRE

Beide Pfade müssen Zugriff auf das verschlüsselte Betriebssystem erhalten können.

Genau daraus entsteht die spätere Angriffsfläche.

Die Recovery-Partition: Der eigentliche Angriffspunkt

Ein typisches Windows-System sieht vereinfacht etwa so aus:

+--------------------------------+
| EFI System Partition           |
+--------------------------------+

+--------------------------------+
| Recovery Partition             |
|                                |
| WinRE.wim                      |
| ReAgent.xml                    |
| Boot.sdi                       |
| BCD                            |
| ResetConfig.xml                |
+--------------------------------+

+--------------------------------+
| BitLocker Volume (C:)          |
|                                |
| Windows                        |
| Users                          |
| Applications                   |
+--------------------------------+

Viele Administratoren übersehen dabei einen wichtigen Punkt:

Die Recovery-Partition ist normalerweise nicht BitLocker-geschützt.

Das ist keine Fehlkonfiguration.

Sie könnte technisch verschlüsselt sein — der Boot-Manager entsperrt schließlich auch das Betriebssystem-Volume.

Sie ist es aber bewusst nicht: Wäre die Recovery-Umgebung an dieselbe Verschlüsselung gebunden, stünde sie genau dann nicht zur Verfügung, wenn das OS-Volume nicht mehr entsperrt werden kann — also im Reparaturfall.

WinRE wird deshalb auf einer eigenen Partition gehalten, die von der BitLocker-Policy des Betriebssystem-Laufwerks nicht erfasst wird — unabhängig vom Entsperr-Zustand von C:.

Warum Secure Boot das Problem nicht löst

Die nächste häufige Annahme lautet:

Dafür gibt es doch Secure Boot.

Secure Boot löst allerdings ein anderes Problem.

Secure Boot prüft, ob geladene Komponenten von einer vertrauenswürdigen Signaturkette stammen.

Der Ablauf sieht vereinfacht so aus:

UEFI
 |
 v
Secure Boot
 |
 v
Boot Manager
 |
 v
WinRE
 |
 v
BitLocker Unseal
 |
 v
Schwachstelle

Die Angriffe erfolgen nicht vor Secure Boot.

Sie erfolgen nach erfolgreicher Secure-Boot-Validierung innerhalb einer bereits vertrauenswürdigen Umgebung.

Secure Boot funktioniert daher korrekt.

Es schützt lediglich vor einer anderen Angriffsklasse.

Es gibt jedoch eine subtilere Wechselwirkung: Secure Boot vertraut nicht nur der aktuellen, sondern auch älteren, weiterhin gültig signierten Microsoft-Komponenten. Genau diese Eigenschaft macht den weiter unten beschriebenen Downgrade-Angriff möglich — dort wird Secure Boot nicht umgangen, sondern sein Vertrauen in alte, noch nicht widerrufene Signaturen ausgenutzt.

BitUnlocker: Vier Schwachstellen, eine gemeinsame Idee

Die 2025 veröffentlichten BitUnlocker-Schwachstellen unterscheiden sich technisch deutlich.

Die zugrunde liegende Angriffskette ist jedoch nahezu identisch:

Offline Zugriff
        |
        v
Manipulation Recovery-Komponenten
        |
        v
WinRE startet
        |
        v
SYSTEM-Rechte in WinRE
        |
        v
BitLocker bereits entsperrt
        |
        v
Zugriff auf C:

Die einzelnen CVEs nutzen unterschiedliche Komponenten:

  • Boot.sdi
  • ReAgent.xml
  • SetupPlatform.exe
  • ResetSession.xml
  • BCD Recovery Sequences

Die technische Ausprägung unterscheidet sich.

Das Ziel bleibt gleich:

Kontrolle über eine Umgebung erlangen, der BitLocker bereits vertraut.

Für Tiefergehende

Wie konkret eine dieser Schwachstellen auf Byte-Ebene funktioniert, lässt sich am besten an CVE-2025-48800 nachvollziehen (im öffentlichen PoC als CVE-2025-48804 geführt): Die boot.sdi-Containerdatei besitzt eine Blob-Tabelle, deren WIM-Eintrag auf den Speicherort des zu bootenden Abbilds zeigt. Der ungepatchte Boot-Manager prüft den Hash an der ursprünglichen Position, bootet aber an der im Eintrag angegebenen — beides ist nicht aneinander gebunden. Ein Angreifer hängt sein eigenes WIM an die Datei an und biegt den Offset um: Das Original wird verifiziert, das manipulierte Abbild gestartet. Kombiniert mit einem älteren, PCA-2011-signierten Boot-Manager entsteht daraus eine SYSTEM-Shell in einer entsiegelten WinRE.

Die vollständige Mechanik (das patch_sdi.py-Skript, die Blob-Table-Indirektion und die PCA-2011-Downgrade-Kette) dokumentiert der öffentliche PoC: garatc/BitUnlocker.

Warum die Patches nicht das Grundproblem lösen

Microsoft hat die einzelnen Schwachstellen gepatcht.

Das bedeutet jedoch nicht, dass die zugrunde liegende Angriffsfläche verschwunden ist.

WinRE wird separat aktualisiert

Die Datei WinRE.wim wird nicht über die normalen kumulativen Windows Updates gepflegt.

Stattdessen kommen sogenannte Safe OS Dynamic Updates zum Einsatz.

Ein System kann deshalb vollständig aktuell erscheinen, während die Recovery-Umgebung deutlich älter ist.

KB5034441 hat das Problem sichtbar gemacht

Anfang 2024 scheiterte KB5034441 auf zahlreichen Windows-Installationen.

Grund war häufig eine zu kleine Recovery-Partition.

Das eigentliche Problem war jedoch organisatorischer Natur:

Viele Administratoren bemerkten nie, dass die Aktualisierung fehlgeschlagen war.

Nicht jede Angriffsfläche liegt in der WIM

Mehrere Angriffspfade betreffen Dateien außerhalb der eigentlichen WinRE.wim.

Dazu gehören beispielsweise:

  • ReAgent.xml
  • BCD
  • Boot.sdi
  • ResetSession.xml

Entscheidend ist hier der Messumfang des TPM: Gemessen wird die WIM-Datei — nicht die umliegenden, unsignierten Konfigurationsdateien auf der Recovery-Partition.

TPM-Messung
    |
    |-- WinRE.wim        -> gemessen, signiert
    |
    +-- ReAgent.xml      -> NICHT gemessen
       BCD                 NICHT gemessen
       Boot.sdi            NICHT gemessen
       ResetSession.xml    NICHT gemessen

Genau deshalb überleben Angriffe wie CVE-2025-48003 (ReAgent.xml) oder CVE-2025-48818 (BCD) auch dann, wenn die WinRE.wim selbst gepatcht ist: Sie verändern eine Datei, die nie in eine PCR einfließt. Diese Komponenten sind für die Vertrauenskette relevant, liegen aber außerhalb des gemessenen Recovery-Images.

Der signierte Downgrade: Warum selbst ein gepatchtes WinRE nicht genügt

Bis hierhin ließe sich einwenden: Dann aktualisiere ich eben WinRE konsequent, und das Problem ist gelöst.

Diese Annahme greift zu kurz — und zwar aus einem grundlegenden Grund.

Ein Angreifer mit Offline-Zugriff ist nicht darauf angewiesen, die auf dem System vorhandene WinRE.wim anzugreifen. Er kann eine ältere, weiterhin gültig von Microsoft signierte Version von Boot-Manager und Recovery-Umgebung mitbringen, die die bereits gepatchten Schwachstellen noch enthält.

Angreifer bringt mit:
älteres, signiertes bootmgfw.efi / WinRE.wim
        |
        v
Secure Boot prüft Signatur
        |
        v
Signatur gültig (PCA 2011 in db, nicht in dbx)
        |
        v
Alte Schwachstellenkette läuft
        |
        v
SYSTEM-Kontext in WinRE

Der Kern: Secure Boot prüft, ob eine Signatur gültig ist — nicht, ob sie aktuell ist. Solange das zugehörige Microsoft-Zertifikat (historisch “Windows Production PCA 2011”) in der erlaubten Datenbank db steht und nicht über die Sperrliste dbx widerrufen wurde, akzeptiert die Firmware auch eine zwei Jahre alte, verwundbare Komponente — etwa von einem USB-Stick.

Warum Microsoft das nicht einfach wegpatcht

Der naheliegende Gedanke lautet: Dann widerruft Microsoft eben die alten Signaturen über dbx.

Das geschieht in der Praxis nur sehr zögerlich. Eine fehlerhafte oder zu breite dbx-Sperrung kann Systeme unbootbar machen — ein widerrufenes Boot-Binary, das noch irgendwo auf einer Wiederherstellungs- oder Installationsumgebung liegt, führt zum Totalausfall. Der Präzedenzfall BlackLotus hat gezeigt, dass solche Revocations über ein Jahr brauchen, bis sie breit ausgerollt sind, und selbst dann oft nur per manuellem Opt-in greifen.

Solange die alten Signaturen nicht flächendeckend in dbx stehen, bleibt der Downgrade-Pfad offen — unabhängig davon, wie aktuell das auf dem System installierte WinRE ist.

Das erweiterte PCR-Profil (PCR 0/2/4) wäre hier ein wirksamer Hebel: Es würde den Austausch des Boot-Managers bemerken und das Unsealing verweigern. Standardmäßig ist es jedoch nicht aktiv.

YellowKey: Warum die Geschichte 2026 erneut begann

Im Mai 2026 wurde die Schwachstelle YellowKey veröffentlicht.

Die technische Umsetzung unterscheidet sich von BitUnlocker, die Vertrauenskette bleibt jedoch dieselbe.

Vereinfacht:

BootExecute
      |
      v
autofstx.exe
      |
      v
Replay von NTFS-Transaktionen
      |
      v
Manipulation von WinRE-Dateien
      |
      v
Fallback auf cmd.exe
      |
      v
SYSTEM-Kontext

YellowKey zeigt erneut:

Die Kryptografie von BitLocker wird nicht gebrochen.

Stattdessen wird eine Umgebung angegriffen, die bereits Zugriff auf das entschlüsselte Betriebssystem besitzt.

TPM-only versus TPM+PIN

Für die Praxis ist diese Unterscheidung entscheidend.

TPM-only

TPM
 |
 v
Automatische Freigabe
 |
 v
Windows startet

Ein Angreifer mit physischem Zugriff kann versuchen, die Vertrauenskette rund um WinRE auszunutzen.

TPM + PIN

TPM
 |
 v
PIN erforderlich
 |
 v
Unseal
 |
 v
Windows startet

Ohne Kenntnis der PIN kann der Angreifer den automatischen Entsiegelungspfad nicht nutzen.

Für verlorene oder gestohlene Geräte bleibt TPM+PIN deshalb eine der wirksamsten Schutzmaßnahmen.

Welche Fragen Unternehmen beantworten können sollten

Die wichtigste Frage lautet nicht:

Ist BitLocker aktiviert?

Sondern:

  • Welche WinRE-Version läuft auf meinen Endgeräten?
  • Werden Safe OS Dynamic Updates erfolgreich installiert?
  • Wo wird TPM-only verwendet?
  • Wo wird TPM+PIN verwendet?
  • Wird WinRE überhaupt benötigt?
  • Werden Recovery-Boots überwacht?
  • Können ältere Recovery-Komponenten erkannt werden?

Wer diese Fragen nicht beantworten kann, kennt möglicherweise nicht den tatsächlichen Sicherheitszustand seiner Endgeräte.

Erste konkrete Prüfschritte

Ein Einstieg lässt sich mit Bordmitteln machen. Status und Pfad der Recovery-Umgebung:

reagentc /info

Anschließend die tatsächliche Version der WinRE-Abbilddatei prüfen — sie verrät, ob die Safe OS Dynamic Updates überhaupt angekommen sind:

Get-WindowsImage -ImagePath "R:\Recovery\WindowsRE\winre.wim" -Index 1 | Select-Object Version, SPBuild

Und schließlich, ob das System überhaupt im TPM-only-Modus läuft oder bereits eine PIN verlangt:

manage-bde -protectors -get C:

Weichen WinRE-Version und installierter Patch-Stand deutlich voneinander ab, oder zeigt der Protektor ausschließlich “TPM”, besteht Handlungsbedarf.

Fazit

BitUnlocker und YellowKey zeigen keine Schwäche der BitLocker-Kryptografie.

Sie zeigen vielmehr, dass moderne Angriffsketten die Vertrauensannahmen rund um BitLocker ausnutzen.

Wer BitLocker verstehen möchte, muss die gesamte Kette betrachten:

UEFI
 |
 v
Secure Boot
 |
 v
Boot Manager
 |
 v
TPM PCRs
 |
 v
WinRE
 |
 v
Windows

Die eigentliche Lektion lautet daher:

BitLocker schützt Daten nicht allein durch Verschlüsselung.

BitLocker schützt Daten durch Vertrauen.

Und genau dieses Vertrauen ist heute das primäre Angriffsziel.

Quellen

Schlagwörter

#BitLocker #Windows #WinRE #BitUnlocker #YellowKey #CVE-2026-45585

Über den Autor

Alexander Sturz

Gründer & Red Team Lead

Active Directory Ninja und Experte für offensive Sicherheit mit Spezialisierung auf Kompromittierung von Unternehmensinfrastrukturen und Post-Exploitation-Techniken.

Verwandte Artikel