Ein bekannter Bypass kehrt zurück — diesmal mit PoC
Anfang Mai berichtete Heise über einen praxistauglichen Angriff, der die BitLocker-Festplattenverschlüsselung über die Windows Recovery Environment (WinRE) umgeht. Sicherheitsforscher von Intrinsec haben den von Microsofts STORM-Team beschriebenen Schwachstellenkomplex „BitUnlocker" zu einem funktionierenden Proof-of-Concept ausgebaut. Microsoft hatte die zugrundeliegende Lücke CVE-2025-48804 (CVSS 6.8) im Juli-Patchday 2025 geschlossen — doch der eigentliche Angriff funktioniert weiterhin gegen vollständig aktualisierte Systeme. Der Grund liegt in einer architektonischen Schwäche, nicht in einem fehlenden Patch.
Für Unternehmen, die BitLocker als Schutz gegen Diebstahl, Verlust oder physische Übergriffe auf Endgeräte einsetzen, ist das ein unangenehmes Signal. Die gute Nachricht: Es gibt zwei klar definierte Verteidigungsmaßnahmen — eine wirkt sofort, die andere ist ohnehin bis Herbst 2026 Pflicht.
Wie der Angriff funktioniert
Der Angriffsablauf wirkt auf den ersten Blick technisch, hat aber einen einfachen Kern: Secure Boot prüft, welches Zertifikat einen Bootloader signiert hat — aber nicht, ob dieser Bootloader bereits durch eine bekannte Sicherheitslücke ersetzt wurde.
Ein Angreifer mit physischem Zugriff auf das Gerät bringt eine vorbereitete USB-Stick- oder PXE-Boot-Umgebung mit. Diese liefert eine ältere, mit der Microsoft Windows Production PCA 2011 signierte bootmgfw.efi — also einen verwundbaren Boot-Manager aus der Zeit vor dem Juli-Patch. Aus Sicht von Secure Boot ist diese Datei vollkommen gültig: Sie trägt eine Microsoft-Signatur, das Zertifikat liegt im DB-Store des UEFI, also wird sie ausgeführt.
Anschließend nutzt der angreifende Boot-Manager die ursprüngliche Schwachstelle im System-Deployment-Image-Mechanismus (SDI). WinRE wird normalerweise als Windows Imaging Format (WIM) innerhalb einer SDI-Datei geladen, deren Integrität geprüft wird. Der ungepatchte Boot-Manager verifiziert allerdings nur das erste WIM in der SDI-Blob-Tabelle, startet aber tatsächlich aus einem zweiten, vom Angreifer manipulierten WIM. In diesem zweiten WIM steckt eine modifizierte WinRE-Umgebung, in der cmd.exe automatisch gestartet wird.
Bis zu diesem Punkt hat sich der TPM-Zustand aus Sicht der Plattform nicht verändert: Die PCR-Messungen passen zur erwarteten Boot-Kette, weil ein offiziell signierter — wenn auch veralteter — Boot-Manager gestartet wurde. Der TPM gibt den BitLocker-Volume-Master-Key frei. Im Ergebnis liegt die entschlüsselte Systempartition vor den Augen einer Eingabeaufforderung, gestartet aus WinRE, mit System-Rechten.
Der gesamte Angriff dauert laut Intrinsec wenige Minuten und benötigt keine Spezial-Hardware.
Welche Konfigurationen betroffen sind
Verwundbar sind Geräte, die alle drei folgenden Bedingungen erfüllen:
- BitLocker arbeitet im sogenannten TPM-only-Modus, also ohne Pre-Boot-Authentifizierung per PIN oder USB-Startschlüssel.
- Im Secure-Boot-DB-Store ist die Microsoft Windows Production PCA 2011 weiterhin als vertrauenswürdig hinterlegt — der Standardzustand auf praktisch allen produktiv eingesetzten Geräten.
- In der Secure-Boot-Sperrliste DBX wurde der alte, verwundbare Boot-Manager nicht explizit blockiert.
In der Praxis bedeutet das: Die überwältigende Mehrheit aller Windows-Geräte mit BitLocker ist aktuell verwundbar. TPM-only ist die unsichtbare Standardkonfiguration, mit der BitLocker bei Erstinstallation, bei AutoPilot-Provisioning oder über Intune-Verschlüsselungsrichtlinien typischerweise aktiviert wird, weil sie für Endanwender bequem ist und keinen zusätzlichen Schulungsbedarf erzeugt.
Warum ein Patch allein nichts ändert
Microsoft hat im Juli 2025 einen reparierten bootmgfw.efi verteilt, der die SDI-Doppellade-Lücke schließt. Sobald dieser auf einem Gerät läuft, ist CVE-2025-48804 lokal behoben. Der Trick des Angreifers besteht aber gerade darin, diesen Patch zu umgehen — indem er die alte Datei einspielt und Secure Boot sie als gültig akzeptiert.
Das ist eine klassische Downgrade-Attacke und keine Besonderheit von BitLocker. Solange in den Secure-Boot-Datenbanken eines Geräts ein altes Signaturzertifikat als vertrauenswürdig steht und der zugehörige verwundbare Boot-Manager nicht in der DBX gesperrt ist, kann er jederzeit „nachgereicht" werden. Genau hier kommt die UEFI-CA-2023-Migration ins Spiel.
Die Verbindung zur UEFI CA 2023 Migration
Wir haben die Hintergründe der laufenden Microsoft-Zertifikatsablösung in unserem Migrations-Leitfaden zur UEFI CA 2023 ausführlich beschrieben. Verkürzt: Die Secure-Boot-Zertifikate aus 2011 — darunter die hier ausgenutzte Microsoft Windows Production PCA 2011 — laufen zwischen Juni und Oktober 2026 ab und werden durch eine neue Zertifikatsgeneration ersetzt. Microsoft liefert dazu parallel die neuen Schlüssel in die Firmware-Stores aus und sperrt verwundbare Komponenten über die DBX.
Für den BitUnlocker-Angriff ergeben sich daraus zwei Effekte:
Mittelfristig (ab Migrationsabschluss): Sobald ein Gerät auf die Windows UEFI CA 2023 migriert wurde, der Boot-Manager mit dem neuen Zertifikat signiert ist und die alte PCA 2011 aus dem DB-Store entfernt oder revoziert wurde, akzeptiert Secure Boot die alten verwundbaren Bootloader schlicht nicht mehr. Der Angriff fällt in sich zusammen.
Spätestens Oktober 2026: Die PCA 2011 läuft kryptografisch aus. Selbst ohne aktive Revokation ist sie dann nicht mehr für die Signaturprüfung gültig — vorausgesetzt, das Gerät hat aktuelle Firmware und respektiert das Ablaufdatum. In der Praxis sehen wir hier jedoch häufig nachlässige Firmware-Implementierungen, weshalb wir uns auf das automatische Ablaufverhalten nicht verlassen würden.
Der Angriff hat damit faktisch ein Verfallsdatum — aber die Frist ist eng. Wer seine Flotte erst ab Herbst 2026 migriert, bleibt ein Jahr lang offen für einen Angriff, der mit veröffentlichtem PoC-Code, USB-Stick und fünf Minuten physischem Zugriff funktioniert.
Die einzige Sofortmaßnahme: BitLocker mit PIN
Intrinsec bringt es in seinem Bericht auf den Punkt: Die einzig zuverlässig wirksame Sofortmaßnahme ist die Aktivierung einer Pre-Boot-PIN für BitLocker. Der Grund ist strukturell, nicht implementierungsabhängig.
Mit einer Pre-Boot-PIN entsiegelt das TPM den BitLocker-Schlüssel erst, wenn die korrekte PIN eingegeben wurde. Ein automatisiertes Booten in eine manipulierte WinRE-Umgebung scheitert dann zwangsläufig — das TPM gibt den Volume-Master-Key niemals frei, ohne dass ein Mensch vor dem Gerät interagiert. Der Angriffspfad ist damit unterbrochen, unabhängig davon, ob die alten Zertifikate noch im DB-Store stehen.
Microsoft beschreibt dasselbe Verhalten seit Jahren in den offiziellen BitLocker-Countermeasures — bereits gegen frühere Bypass-Forschung (etwa „bitpixie") ist die Pre-Boot-PIN die empfohlene Verteidigung. Auch das BSI hat seit langem Pre-Boot-Authentifizierung als notwendige Ergänzung zu TPM-basierter Festplattenverschlüsselung positioniert, insbesondere für mobile Geräte.
Was eine sinnvolle PIN-Konfiguration ausmacht
Die Pre-Boot-PIN ist kein Anwender-Passwort und muss anderen Regeln folgen. Sie wird nicht über das Netzwerk übertragen, lässt sich nicht remote ausprobieren und ist nach mehreren Fehlversuchen durch das TPM-Lockout-Verhalten ohnehin gesperrt. In der Praxis hat sich folgende Konfiguration bewährt:
- Mindestlänge 6–8 Zeichen. Microsoft erlaubt 4–20 Zeichen; vier sind angesichts moderner TPM-Lockouts noch akzeptabel, aber knapp.
- Enhanced PINs aktivieren (Gruppenrichtlinie „Allow enhanced PINs for startup"), damit auch Buchstaben und Sonderzeichen zugelassen sind — die PIN muss kein reiner Zahlencode sein.
- TPM-Lockout-Werte nicht abschwächen. Standardmäßig sperrt das TPM nach wenigen Fehlversuchen für längere Zeit. Diese Verteidigung verträgt keine „Komfort-Anpassungen".
- Recovery-Key separat sichern. Pre-Boot-PIN ersetzt nicht den Recovery-Key — der gehört weiterhin in Entra ID, Active Directory oder einen Passwortmanager mit kontrolliertem Zugriff.
Für Geräte ohne Tastatur (Tablets, 2-in-1) lässt sich die Eingabe per Touch-Keyboard im UEFI realisieren; alternativ kommt ein TPM+USB-Startup-Key in Betracht. TPM-only sollte in keinem Szenario die Standardkonfiguration bleiben.
Rollout in bestehenden Flotten
Das größte praktische Hindernis ist die Umstellung bereits verschlüsselter Geräte. Eine neu vergebene PIN lässt sich über manage-bde -protectors -add C: -TPMAndPIN ergänzen, ohne das Volume neu zu verschlüsseln. Über Intune steuert die Konfiguration „Configuration profiles → Disk Encryption → BitLocker" mit den Parametern Require additional authentication at startup = Yes und Configure TPM startup PIN = Require startup PIN with TPM. Per Gruppenrichtlinie liegt die Stellschraube unter Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → BitLocker-Laufwerkverschlüsselung → Betriebssystemlaufwerke → Zusätzliche Authentifizierung beim Start anfordern.
Wichtig ist dabei das Roll-out-Design. Eine zentral erzwungene Richtlinie löst auf TPM-only-Geräten keine PIN-Vergabe aus, sondern blockiert den nächsten Reboot, bis der Anwender selbst eine PIN setzt. Wir empfehlen in der Praxis ein zweistufiges Vorgehen: zuerst die Richtlinie als „Allow Startup PIN" konfigurieren und eine Self-Service-Kampagne fahren (mit klarer Anleitung, IT-Begleitung und Backup-Plan für vergessene PINs), dann nach einigen Wochen auf „Require" umstellen.
Härtungschecks, die jetzt zählen
Aus unserer Arbeit zur Systemhärtung sehen wir mehrere wiederkehrende Befunde, die das Risiko hinter BitUnlocker zusätzlich vergrößern:
- Boot aus externen Medien nicht deaktiviert. Viele Endgeräte erlauben weiterhin USB- oder PXE-Boot, häufig sogar ohne UEFI-Admin-Passwort. Ein Angreifer benötigt damit nicht einmal Werkzeug, um die Bootreihenfolge zu ändern.
- Kein UEFI-Setup-Passwort. Ohne Passwort lassen sich Secure-Boot-Status, Boot-Reihenfolge und Wiederherstellungs-Optionen frei umkonfigurieren. Damit fällt die Verteidigung in Schicht eins komplett aus.
- Standardmäßige Recovery-Optionen. WinRE ist auf den meisten Geräten ohne weitere Schutzmaßnahmen aktiv. Mit Pre-Boot-PIN ist das beherrschbar; ohne PIN ist es ein zusätzliches Einfallstor.
- DBX-Updates nicht eingespielt. Auch unabhängig vom UEFI-CA-2023-Wechsel verteilt Microsoft regelmäßig DBX-Updates, die bekannt verwundbare Boot-Komponenten sperren. Wir finden in Assessments häufig DBX-Stände, die mehrere Jahre zurückliegen.
Die folgende Tabelle fasst zusammen, welche Maßnahme welches Teilrisiko adressiert:
| Maßnahme | Wirkung gegen BitUnlocker | Aufwand |
|---|---|---|
| BitLocker mit Pre-Boot-PIN | Sofort wirksam — TPM gibt Schlüssel nicht frei | Mittel (Rollout-Kampagne) |
| UEFI CA 2023 Migration abschließen | Mittelfristig wirksam — alte Bootloader nicht mehr signaturgültig | Hoch (gesteuerter Flotten-Rollout) |
| DBX-Updates aktuell halten | Sperrt einzelne verwundbare Bootloader | Niedrig (Windows Update) |
| UEFI-Setup-Passwort | Verhindert Konfigurationsänderung am Gerät | Niedrig (Pflichtsetzung über OEM-Tooling) |
| Boot aus externen Medien deaktivieren | Erhöht die Angriffsschwelle deutlich | Niedrig (UEFI-Setting) |
Keine dieser Maßnahmen ist neu — sie alle stehen seit Jahren in Härtungsleitfäden, etwa in den CIS-Benchmarks für Windows 11 oder im BSI-Grundschutz-Baustein SYS.2.1. Der BitUnlocker-PoC verschiebt sie nur von „sollte" zu „muss".
Welche Geräte besonders im Fokus stehen
Nicht jedes Gerät trägt das gleiche Risiko. Die größte Gefährdung sehen wir bei:
Mobilen Endgeräten. Laptops im Außendienst, im Homeoffice oder auf Geschäftsreise sind das primäre Ziel. Ein verlorenes oder gestohlenes Gerät ohne Pre-Boot-PIN ist mit dem PoC innerhalb weniger Minuten kompromittiert. Bei Geräten mit personenbezogenen Daten ist das nicht nur ein Sicherheits-, sondern auch ein DSGVO-Vorfall.
Geräten in zugänglichen Bereichen. Empfangsrechner, Schulungsräume, Werkstattlaptops, KMU-Büros ohne Zutrittskontrolle. Hier reicht ein kurzer unbeobachteter Moment.
Domänengebundenen Clients mit hohen Privilegien. Wer das Volume eines Admin-Endgeräts entschlüsselt, hat Zugriff auf Tickets, Caches, Browser-Sessions und gelegentlich Schlüsselmaterial. Das ist eine Brücke ins Active Directory, die nicht über das Netzwerk geht und entsprechend selten überwacht wird.
Industrie- und OT-Geräte. Engineering-Workstations, HMIs, Wartungs-Notebooks. Häufig läuft auf ihnen Windows mit BitLocker, der Standortzugang ist physisch oft schlechter geschützt als im Büro.
Was wir in Assessments sehen — und was es bedeutet
In Systemhärtungs-Assessments prüfen wir BitLocker-Konfigurationen routinemäßig. Der häufigste Befund ist eindeutig: TPM-only ohne Pre-Boot-PIN, kombiniert mit fehlendem UEFI-Setup-Passwort und einem DBX-Stand, der älter ist als ein Jahr. Diese Konstellation gibt es nicht nur in kleineren Mittelständlern, sondern auch in größeren Unternehmen mit etablierten IT-Abteilungen — schlicht, weil sie über Jahre als „sicher genug" galt.
Der BitUnlocker-PoC ändert die Bewertungsgrundlage. Eine Verschlüsselung, die einen Angreifer mit physischem Zugang fünf Minuten lang aufhält, ist im Sinne der DSGVO Art. 32 und der NIS2-Richtlinie keine angemessene technisch-organisatorische Maßnahme mehr — jedenfalls nicht für mobile Endgeräte mit personenbezogenen Daten. Es ist absehbar, dass Versicherungen und Auditoren diese Konfiguration in den nächsten Monaten kritischer bewerten werden.
Die Verbindungslinie: Boot-Kette als Vertrauensanker
Die UEFI-CA-2023-Migration, die BlackLotus-Revokation und der BitUnlocker-PoC sind drei Symptome derselben Wahrheit: Die Boot-Kette eines Windows-Geräts ist nicht ein einzelnes Feature, sondern ein zusammenhängendes Vertrauenssystem. Wer Secure Boot, Measured Boot, TPM-Bindung und Pre-Boot-Authentifizierung als optionale Bausteine betrachtet, verliert die Fähigkeit, einzelne Komponenten zu härten, ohne den Rest zu kompromittieren.
Defense-in-Depth bedeutet hier konkret: Pre-Boot-PIN schützt vor dem Downgrade-Angriff. CA-2023-Migration zieht später dem Angriff die Grundlage weg. DBX-Updates schließen einzelne bekannte Lücken. Und ein gesetztes UEFI-Setup-Passwort verhindert, dass diese Verteidigungen am Gerät selbst weggeklickt werden. Keine dieser Schichten reicht allein.
Fazit
Der BitUnlocker-PoC ist keine neue, exotische Angriffsklasse. Er kombiniert eine bekannte WinRE-Lücke mit einer bekannten architektonischen Schwäche von Secure Boot zu einem belastbaren Werkzeug, das jeder mit physischem Zugriff und einem USB-Stick einsetzen kann. Die Antwort ist ebenso wenig neu: Pre-Boot-PIN für BitLocker, konsequente UEFI-CA-2023-Migration, aktueller DBX-Stand, UEFI-Setup-Passwort.
Wer beide Hebel umsetzt — den schnellen (PIN) und den strategischen (CA-2023) — bringt seine Flotte aus der akuten Angriffsfläche und stellt die Vertrauenskette für die nächste Geräte-Generation auf eine saubere Grundlage.
BitLocker-Härtung und Secure-Boot-Migration in einem Schritt prüfen lassen. In unserem Systemhärtungs-Assessment erfassen wir den BitLocker-Modus, die UEFI-CA-2023-Migrationsbereitschaft, den DBX-Stand und die UEFI-Setup-Absicherung Ihrer Flotte — und liefern einen priorisierten Maßnahmenplan inklusive Rollout-Sequenz für Pre-Boot-PIN und Zertifikatsmigration. Jetzt Systemhärtungs-Assessment anfragen.