BitUnlocker knackt BitLocker auf Windows 11 in unter fünf Minuten. Betroffen sind TPM-only-Systeme ohne PIN.
BitLocker soll Windows-Laptops vor neugierigen Blicken schützen. Ein neuer Proof of Concept (PoC) zeigt jedoch, dass auf vielen Windows-11-Systemen bereits physischer Zugriff, ein vorbereiteter USB-Stick und ein alter, aber weiterhin vertrauenswürdiger Bootmanager ausreichen. Damit steht das verschlüsselte Laufwerk für Angreifer offen. BitUnlocker nutzt keinen geknackten Schlüssel, sondern Microsofts eigenes Vertrauensmodell. Der Angriff zeigt, wie gefährlich alte Secure-Boot-Zertifikate, TPM-only-BitLocker ohne zusätzliche PIN-Abfrage und nicht abgeschlossene Secure-Boot-Umstellungen werden können.
Secure Boot wird zum Einfallstor
Mit BitUnlocker ist ein neuer Proof of Concept öffentlich geworden, der BitLocker-geschützte Windows-11-Systeme sowie Windows Server 2022 und 2025 in wenigen Minuten angreifbar machen kann. Der Knackpunkt ist nicht, dass BitLocker kryptografisch gebrochen wäre. Vielmehr missbraucht der Angriff die Art, wie Windows, Secure Boot, WinRE und TPM beim Start zusammenspielen. Das Ergebnis ist ein entsperrtes Laufwerk, obwohl der Besitzer nie sein Passwort eingegeben hat.
Laut Sicherheitsforscher Cassius Garat und seinem GitHub-Projekt garatc/BitUnlocker funktioniert der Angriff gegen vollständig gepatchte Windows-11-Systeme, sofern diese noch einem alten Microsoft-Windows-PCA-2011-signierten Bootmanager vertrauen. Die Grundlage ist CVE-2025-48804, eine von Microsoft dokumentierte BitLocker-Sicherheitslücke, bei der Angreifer mit physischem Zugriff die Verschlüsselung umgehen können. Die Schwachstelle betrifft den Windows-Startprozess beziehungsweise die Windows Recovery Environment (WinRE).
BitUnlocker hebelt BitLocker aus
Technisch hängt BitUnlocker an der Windows Recovery Environment, kurz WinRE. Der Bootmanager lädt dabei ein SDI-Image und eine referenzierte WIM-Datei. Die Integrität der legitimen WIM wird geprüft, während über eine manipulierte Struktur gleichzeitig eine zweite, vom Angreifer kontrollierte WIM geladen wird.
Diese zweite WIM startet eine manipulierte WinRE-Umgebung, die am Ende eine cmd.exe mit bereits entschlüsseltem BitLocker-Laufwerk öffnet. Das TPM gibt den BitLocker-Schlüssel frei, weil die manipulierte Bootkette für das System weiterhin vertrauenswürdig erscheint. Der Angriff benötigt laut den Forschern nur physischen Zugriff, einen vorbereiteten USB-Stick oder PXE-Boot sowie wenige Minuten Zeit. Spezialhardware oder aufwendige TPM-Attacken sind dafür hingegen nicht notwendig.
BitUnlocker missbraucht Microsofts Vertrauenskette
Microsoft hatte die ursprüngliche Schwachstelle bereits im Juli 2025 gepatcht. Secure Boot prüft allerdings nicht, ob ein Bootmanager aktuell oder sicher ist. Entscheidend ist lediglich, ob dessen Signatur beziehungsweise Zertifikat weiterhin als vertrauenswürdig gilt. Dies öffnet das Einfallstor für BitUnlocker.
Ein alter, verwundbarer bootmgfw.efi, der noch mit dem Zertifikat „Microsoft Windows PCA 2011“ signiert wurde, gilt für Secure Boot weiterhin als legitim. Dadurch lässt sich ein Downgrade-Angriff durchführen. Das System bootet mit einem alten, anfälligen Bootmanager, obwohl eigentlich längst ein gepatchter vorhanden wäre.
Sicherheitsforscher Cassius Garat beschreibt auf Intrinsec treffend, dass nicht der fehlende Patch das Problem ist, sondern die weiterhin akzeptierte alte Vertrauenskette.
TPM-only-BitLocker wird zum Risiko
Betroffen sind Systeme mit sogenanntem TPM-only-BitLocker. Dabei entsperrt das TPM (Trusted Platform Module) das Laufwerk beim Systemstart automatisch ohne zusätzliche PIN-Abfrage. Diese Komfortfunktion macht die Angriffe überhaupt erst praktikabel.
Sobald ein manipuliertes Boot-Szenario vom TPM akzeptiert wird, gibt dieses den BitLocker-Schlüssel frei und das Laufwerk steht offen. Systeme mit TPM + PIN sind erheblich besser geschützt, weil dort zusätzlich Benutzerinteraktion notwendig wird.
BitLocker soll eigentlich verhindern, dass gestohlene oder verlorene Geräte ausgelesen werden können. Der Angriff funktioniert zwar nicht aus der Ferne über das Internet, wohl aber bei physischem Zugriff auf ein Gerät, etwa bei gestohlenen Notebooks, unbeaufsichtigten Firmenlaptops oder kurzfristigem Zugriff durch Insider. Mobile Windows-11-Geräte geraten dadurch stärker in den Fokus.
Ohne KB5025885 bleibt die Lücke offen
Microsoft empfiehlt seit längerem die Migration auf die neueren Secure-Boot-Zertifikate rund um „Windows UEFI CA 2023“. Dafür gibt es KB5025885. Das Problem liegt in der weiterhin aktiven PCA-2011-Vertrauenskette. Solange sie nicht widerrufen wird, akzeptiert Secure Boot verwundbare Bootmanager.
Die Problematik rund um alte Signaturen und akzeptierte Vertrauenseinträge beschäftigt Microsoft derzeit auch an anderer Stelle. Erst vor wenigen Wochen kündigte der Konzern Maßnahmen gegen Hypervisor-Cracks und veraltete signierte Treiber unter Windows 11 an.
Administratoren sollten sich nicht allein auf klassisches Patchmanagement verlassen. Entscheidend ist vielmehr die tatsächlich verwendete Bootkette einschließlich der Zertifikate, der EFI-Partition und der aktiven Signaturpfade. Der aktive bootmgfw.efi auf der EFI-Partition muss tatsächlich mit CA 2023 signiert sein. Eine gepatchte Datei im Windows-Verzeichnis allein schützt nicht, wenn beim Systemstart weiterhin ein alter, verwundbarer Bootmanager verwendet wird.
Frust über Microsoft treibt die Veröffentlichungen an
Zusätzliche Aufmerksamkeit erhält die aktuelle BitLocker-Debatte durch den Sicherheitsforscher „Chaotic Eclipse“, der unter anderem über den GitHub-Account „Nightmare-Eclipse“ mehrere Windows-Zero-Day-Exploits und Proofs of Concept veröffentlicht hat, darunter YellowKey und GreenPlasma.
Zuvor hatte der Forscher bereits die Windows-Schwachstellen BlueHammer und RedSun veröffentlicht, die laut BleepingComputer kurz nach ihrer öffentlichen Bekanntgabe aktiv ausgenutzt wurden. Chaotic Eclipse kündigte zudem an, weiterhin Exploits für undokumentierte Windows-Schwachstellen veröffentlichen zu wollen. Für den nächsten Patch Tuesday stellte der Forscher sogar eine „große Überraschung“ in Aussicht.
Als Begründung nennt der Forscher laut eigenen Aussagen Frust über Microsofts Umgang mit gemeldeten Schwachstellen. In Blogeinträgen wirft er dem Konzern unter anderem vor, Sicherheitslücken stillschweigend zu patchen oder Hinweise von Forschern nicht ausreichend ernst zu nehmen.
Weiteren Zündstoff liefert dabei seine Behauptung, Microsoft habe einzelne Schwachstellen ohne öffentliche Sicherheitswarnung geschlossen. Ob diese Vorwürfe vollständig zutreffen, lässt sich derzeit allerdings nicht unabhängig überprüfen. Mehrere Medien haben die Konflikte bereits aufgegriffen, darunter BleepingComputer.
YellowKey und GreenPlasma verschärfen die Lage zusätzlich
Mit YellowKey veröffentlichte Chaotic Eclipse außerdem einen weiteren Angriff auf BitLocker und WinRE. Die Sicherheitsforscher Kevin Beaumont und Will Dormann konnten die grundlegende Funktionsweise des Angriffs nach eigenen Angaben reproduzieren, wie BleepingComputer berichtete. Betroffen sind insbesondere TPM-only-BitLocker-Systeme.
Dabei werden speziell vorbereitete FsTx-Dateien auf einem USB-Stick oder direkt auf der EFI-Partition platziert. Nach dem Neustart in die Windows Recovery Environment und dem Gedrückthalten der STRG-Taste soll unmittelbar eine Shell mit Zugriff auf das entschlüsselte BitLocker-Laufwerk erscheinen.
Laut Will Dormann funktionierte der Angriff in seinen Tests zuverlässig über ein USB-Laufwerk, nicht jedoch über die EFI-Partition. Dormann zufolge sucht WinRE beim Start nach speziellen FsTx-Verzeichnissen auf angeschlossenen Datenträgern und verarbeitet dabei NTFS-Transaktionsprotokolle. Dadurch werde unter anderem die Datei X:\Windows\System32\winpeshl.ini manipuliert, sodass statt der eigentlichen Wiederherstellungsumgebung unmittelbar eine cmd.exe gestartet werde.
Nach Einschätzung Dormanns funktioniert der derzeit veröffentlichte YellowKey-Exploit allerdings nicht gegen ausgebaute, gestohlene Laufwerke, da dafür weiterhin das originale TPM des Zielsystems benötigt wird. TPM-plus-PIN-Konfigurationen gelten beim aktuellen öffentlichen Exploit zudem weiterhin als besser geschützt. Chaotic Eclipse behauptet allerdings, auch TPM-plus-PIN-Konfigurationen grundsätzlich umgehen zu können. Einen entsprechenden Proof of Concept habe der Forscher bewusst bisher nicht veröffentlicht:
„Nein, TPM+PIN hilft nicht, das Problem ist weiterhin ausnutzbar. Ich habe mir die Frage gestellt: Funktioniert es auch in einer TPM+PIN-Umgebung? Ja, das tut es. Ich veröffentliche den Proof of Concept nur nicht, da ich denke, dass das, was da draußen ist, schon schlimm genug ist.“
Daneben kursiert mit GreenPlasma noch ein unvollständiger Privilege-Escalation-Exploit für Windows 11 und Windows-Server, bei dem laut Autor entscheidende Bestandteile für eine vollständige SYSTEM-Shell fehlen.
Zusammen ergibt sich ein unangenehmes Bild. BitLocker schützt zwar weiterhin zuverlässig gegen klassischen Diebstahl und Offlineangriffe. Die Bootkette rund um WinRE, Secure Boot und TPM entwickelt sich jedoch zu einem bevorzugten Angriffsziel.
Microsoft erklärte gegenüber BleepingComputer, man untersuche gemeldete Sicherheitsprobleme und unterstütze weiterhin koordinierte Offenlegungsverfahren für Sicherheitslücken.
BitLocker besser absichern
Die wichtigste Sofortmaßnahme bleibt die Aktivierung von TPM plus PIN. Wer ausschließlich auf TPM-only-BitLocker setzt, vertraut darauf, dass der gesamte Bootpfad unangreifbar bleibt.
Nutzer und Administratoren sollten deshalb KB5025885 vollständig umsetzen, auf CA 2023 migrieren, alte PCA 2011 Vertrauenseinträge widerrufen, externe Bootoptionen einschränken, die EFI Partition kontrollieren und Recovery Umgebungen zusätzlich absichern.
Mobile Geräte, Außendienst-Notebooks, gemeinsam genutzte Systeme und generell Windows-11-Geräte mit sensiblen Daten geraten durch solche physischen BitLocker-Angriffe stärker in den Fokus potenzieller Angreifer. „BitLocker aktiviert“ bedeutet nicht automatisch mehr „gegen physische Angriffe geschützt“. TPM-only-BitLocker bleibt damit vor allem eine Komfortfunktion mit Sicherheitsrisiko. Microsofts langsame Migration weg von PCA 2011 und die komplizierte Secure-Boot-Übergangsphase verschärfen das Problem zusätzlich.
