--- title: Bitlocker the Neverending Story url: https://www.vidrasec.com/de/blog/bitlocker-the-neverending-story/ description: BitLocker ist nur so gut wie seine Konfiguration: Angriffe wie DMA, bitpixie und YellowKey und was wirklich dagegen schützt. date: 2026-10-02 --- Laufwerksverschlüsselung ist eine der grundlegendsten Maßnahmen für die physische Sicherheit von Endgeräten. Wenn man die IT-Security-Nachrichten ein bisschen verfolgt, kommt es einem aber vor, als würde alle paar Monate eine neue Schwachstelle in BitLocker veröffentlicht werden. In diesem Beitrag erkläre ich die Funktionsweise von BitLocker im Detail, welche Angriffe es gibt und wie man sich dagegen schützen kann. Warum das Ganze überhaupt so wichtig ist: Ohne Laufwerksverschlüsselung geht beim Diebstahl des Geräts nicht nur die Hardware verloren, sondern auch die Daten darauf. Außerdem kann eine bösartige Person problemlos ihre Rechte ausweiten (Local Privilege Escalation). Gestohlene Hardware ist ärgerlich, gestohlene Daten können zu echten Sicherheitsvorfällen oder Datenschutzverletzungen führen. Ein wichtiger Punkt wird hier aber oft vergessen: Verschlüsselung ist nur so gut, wie sie konfiguriert ist. Gerade BitLocker, als am häufigsten benutzte Form der Laufwerksverschlüsselung, muss richtig konfiguriert sein. Denn sonst lässt sich die Verschlüsselung mit genug Know-how komplett aushebeln. Das ist blöd, denn sobald ein Notebook gestohlen wurde, muss man sich auf die Verschlüsselung verlassen können. Ich gehe das hier von unten nach oben durch: zuerst, wie Laufwerksverschlüsselung und die beteiligten Komponenten eigentlich zusammenspielen, dann die konkreten Angriffe und warum sie funktionieren, und am Ende natürlich, was man dagegen machen kann. ## IT-SECX Präsentation Hier ist die Präsentation von der IT-SECX 2026 {{< presentation-embed "de/public-presentations/bitlocker-unendliche-geschichte" >}} ## Grundlagen von BitLocker bzw. Laufwerksverschlüsselung Die Grundlagen von Laufwerksverschlüsselung sind eigentlich relativ simpel. Etablierte Verschlüsselungsalgorithmen werden verwendet, um die Daten zu verschlüsseln. Um sie zu entschlüsseln, muss ein Schlüssel eingegeben werden. Das ist auch gut und sicher, solange gewisse Voraussetzungen erfüllt sind. Der Schlüssel muss lang und nicht erratbar sein, damit er nicht für Offline-Brute-Force-Angriffe anfällig ist. Außerdem muss der Hardware bzw. Firmware, auf der er eingegeben wird, vertraut werden. Ansonsten wäre hier ein Evil-Maid-Angriff möglich. Beispielsweise könnte eine bösartige Person mit Zugriff auf das gesperrte Gerät den Boot-Prozess manipulieren und eine gefälschte Login-Maske anzeigen, die das eingegebene Passwort an die bösartige Person schickt. Hierfür gibt es mittlerweile auch schon eine etablierte Gegenmaßnahme: das Trusted Platform Module (TPM). Ein TPM in Version 2.0 ist beispielsweise eine Mindestanforderung von Windows 11. Entsprechend hat es mittlerweile jedes aktuelle Mainboard eingebaut. Was ist das? Ein Hardware-Modul, das den tatsächlichen BitLocker-Schlüssel speichert (ein bisschen vereinfacht gesagt). Wir als User sehen diesen Key gar nicht mehr. Die PIN, die wir eingeben, wird benutzt, um den eigentlichen Schlüssel freizugeben. Kann man sich vorstellen wie bei einer Bankomatkarte. Meine PIN entsperrt die Bankomatkarte, die enthält dann die Geheimnisse, um die Transaktion auszuführen. Das schützt uns vor Brute-Force-Angriffen: Der eigentliche Schlüssel ist lang und zufällig, ein Durchprobieren ist damit chancenlos. Anfällig wäre hier nur die PIN, diese kann man aber nur über das TPM brute-forcen, und dieses implementiert Gegenmaßnahmen wie z. B., dass nur eine gewisse Anzahl an Fehlversuchen pro Zeiteinheit erlaubt ist ([Anti-Hammering](https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/tpm-fundamentals#anti-hammering)). Vom Prinzip her ähnlich wie auch bei der Bankomatkarte. Das viel wichtigere Feature des TPM ist aber, dass es überprüft, ob sich die Firmware oder Hardware geändert hat. Warum? Ein weiterer Angriffsvektor wäre manipulierte Hard- bzw. Firmware. Also z. B. ein schädliches UEFI-Update. Oder das Booten von einem Fake-Betriebssystem. Genau das überprüft das TPM (je nach Konfiguration der PCR-Profile) aber ebenfalls. Hat sich etwas geändert, entsperrt es nicht mehr. Das tritt zum Beispiel auch auf, wenn man neue Hardware einbaut oder eine Komponente kaputtgeht. Daher immer den Recovery Key aufheben, auch wenn du nicht glaubst, dass du das Passwort vergisst. ![Beide Eigenschaften kommen vom TPM: Brute-Force-Schutz durch die PIN mit Anti-Hammering, und der Hardware-Check über die PCR-Werte](https://www.vidrasec.com/images/blog/bitlocker-tpm-features.de.webp) So weit, so gut. Jetzt hat sich Microsoft aber zwei Dinge einfallen lassen, die das Ganze aufweichen: 1. zentral gespeicherte Recovery Keys und 2. TPM-only-Modus Bei Recovery Keys handelt es sich um Passwörter, die man statt der TPM-PIN eingeben kann. Also zum Beispiel, wenn sich die Hardware geändert hat oder aus einem anderen Grund eine Recovery stattfinden muss. Das ist grundsätzlich gut und wichtig, weil man dadurch immer eine Möglichkeit hat, die Daten zu entschlüsseln, auch ohne TPM. Jetzt kann man sich vorstellen, dass so ein Recovery Key sehr sensibel ist und sicher abgespeichert werden muss. Eine Möglichkeit ist, den Schlüssel auszudrucken und physisch im Safe abzulegen. Es gibt allerdings auch die Möglichkeit, den Schlüssel zentral zu speichern, zum Beispiel im Microsoft-Konto. Meiner Meinung nach ist das für die meisten Use Cases okay, aber man muss im Hinterkopf behalten, dass Microsoft dann die eigene Festplatte entschlüsseln könnte, wenn sie zusätzlich physischen Zugriff auf meine Festplatte hätten. Das ist aber vor allem für Kriminelle relevant (damit die Polizei ihre Notebooks nicht entschlüsseln kann). Zum Zugriff auf die Daten brauche ich immer den Schlüssel **und** das physische Gerät. Anfang 2026 gab es da einen Aufschrei, weil das FBI Zugriff auf die Schlüssel bekommen hat. Eine weitere Möglichkeit (für Unternehmen) ist, die Recovery Keys im Active Directory bzw. Entra ID/Intune abzuspeichern. Das ist auch relativ Standard in Unternehmen, ganz einfach, weil Mitarbeitende ihre PINs vergessen oder UEFI-Updates schiefgehen. Das heißt, die interne IT hat auch die Möglichkeit, die Geräte zu entschlüsseln. Wichtig ist hier einfach zu wissen, dass es mit dem Recovery Key einen zweiten Schlüssel zur Entschlüsselung gibt. Wer den hat, kann mein Gerät entschlüsseln. Zentral gespeicherte Recovery Keys sehe ich eher als Feature denn als Sicherheitslücke. Wenn dir das aber wichtig ist, schau dir an, wo deine Recovery Keys tatsächlich gespeichert sind und wer darauf zugreifen kann. Und dann entscheide basierend auf deinem Threat-Model, ob das ein Problem ist. Spannender ist hier der TPM-only-Modus. Das ist leider auch die Standardeinstellung in Windows, und es ist relativ schwierig, auf den TPM+PIN-Modus zu wechseln (geht z. B. über [Group Policies](https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/configure)). Im TPM-only-Modus gibt es keine PIN mehr. Das TPM entschlüsselt einfach. „Einfach“ ist jetzt übertrieben, denn die Checks, ob Hardware und Firmware verändert wurden, gibt es natürlich trotzdem noch. Das hört sich auf den ersten Blick sehr unsicher an. In der Praxis ist es aber besser. Da die Hard- und Firmware nicht verändert werden können, kann eine bösartige Person hier gar nicht viel machen. Wenn das Gerät normal konfiguriert ist, bootet es einfach zum Windows-Anmeldebildschirm. Und hier gibt es im Normalfall keine Möglichkeit, irgendwelche Daten auszulesen, ohne dass ich ein richtiges Passwort eingebe. Boote ich beispielsweise von einem USB-Stick mit einem fremden Betriebssystem, erkennt das TPM das und gibt den Schlüssel nicht frei. (Ein Microsoft-signierter Bootmanager ist übrigens kein fremdes Betriebssystem, genau darauf baut bitpixie weiter unten auf.) Die bösartige Person braucht jetzt also tatsächlich ein Passwort, um irgendwelche Daten auszulesen. Und selbst dann: Der angemeldete User hat nicht unbedingt Adminrechte. Ohne Adminrechte kann BitLocker nicht deaktiviert werden. Wenn es jetzt keine andere Möglichkeit der Privilege Escalation gibt, dann steht die bösartige Person auch hier an, weil sie nicht alle Daten auslesen kann. ![Drei Key Protectors im Vergleich: alle drei prüfen beim Start Hardware und Firmware, TPM only entsperrt danach ganz ohne Eingabe, TPM plus PIN verlangt zusätzlich die PIN vor dem Boot, und bei geänderter Hardware oder Firmware sperrt das TPM und der Recovery Key wird nötig, der wahlweise zum Windows-Login führt oder einem Angreifer erlaubt, Linux zu booten und die Daten auszulesen](https://www.vidrasec.com/images/blog/bitlocker-key-protectors.de.webp) Großes „Aber“: Jeder einzelne Angriff, den ich kenne, attackiert genau diese TPM-only-Konfiguration. Die Angriffe basieren immer auf anderen Komponenten, nie auf BitLocker selbst. Es gibt zwar eine Aussage vom YellowKey-Entwickler, dass er auch BitLocker in TPM+PIN-Konfiguration angreifen kann. Dieser Angriff setzt aber voraus, dass der User einmal seine PIN auf dem präparierten Notebook eingibt, also eher ein Evil-Maid-Angriff als ein Angriff, der auf einem gestohlenen Notebook funktioniert. Der Autor hat das [selbst beschrieben](https://deadeclipse666.blogspot.com/2026/06/regarding-yellowkey-pintpm.html) und den PoC dafür nicht veröffentlicht. Spannendes Detail: der Yellow-Key Entwickler sagt, dass er selbst BitLocker einsetzt und ist der Meinung, dass BitLocker an sich großartig ist: > I didn't release the PoC because I rely on bitlocker myself, bitlocker is great, the issue is it have to rely on retarded software to function which is a huge flaw. ## Ausgewählte Angriffe Eine sehr schöne [Übersicht über bekannte Angriffe](https://github.com/Wack0/bitlocker-attacks) pflegt Wack0 auf GitHub. Auf ein paar will ich hier im Detail eingehen. ![Fünf Angriffe und die Komponente, die sie jeweils treffen: Cold Boot auf den RAM, DMA auf FireWire, PCIe und Thunderbolt, TPM Sniffing auf den Bus zum TPM, bitpixie auf den Windows Boot Manager, YellowKey auf das Windows Recovery Environment. AES-XTS und BitLocker selbst werden nie angegriffen](https://www.vidrasec.com/images/blog/bitlocker-attack-surface.de.webp) ## Hardware-Angriffe Hardware-Angriffe sind meist beeindruckend zum Vorzeigen und schwer zu beheben, funktionieren aber je nach Angriff nicht auf jedem Gerät zuverlässig. ### DMA-Angriff Einen Direct-Memory-Access-(DMA)-Angriff habe ich 2021 auf der IT-SECX selbst demonstriert. Die Idee ist einfach, dass es gewisse Hardware gibt (z. B. Firewire oder GPUs), die direkt auf den RAM schreiben kann. Jetzt gibt es spezielle Angriffshardware (Stichwort [PCILeech](https://github.com/ufrisk/pcileech)), die ich tatsächlich physisch anschließe. Das Gerät erkennt die Hardware beispielsweise als Grafikkarte. Die Angriffshardware kann nun über den Direct Memory Access direkt in den Speicher schreiben und so Kommandos ausführen. Also zum Beispiel eine Admin-Shell öffnen, auch am Anmeldebildschirm. [YouTube video](https://youtu.be/XL5ejMIrnHc?si=Rp0H-iBgGMYHGLpB) Windows 11 aktiviert auf unterstützter Hardware mittlerweile [Kernel DMA Protection](https://learn.microsoft.com/en-us/windows/security/hardware-security/kernel-dma-protection-for-thunderbolt) standardmäßig.[^dmaoem] Dabei blockiert die IOMMU alle DMA-fähigen Geräte, deren Treiber kein DMA-Remapping unterstützen, solange niemand angemeldet bzw. der Bildschirm gesperrt ist. Nicht abgedeckt sind laut Microsoft übrigens 1394/FireWire, PCMCIA, CardBus und ExpressCard; dafür gibt es eigene BitLocker-Richtlinien. Thunderbolt selbst hatte davon unabhängig auch schon eigene Baustellen (siehe [Thunderspy](https://thunderspy.io), 2020). Hier gibt es wiederum Angriffe, die darauf basieren, dass der [Hardware-Support für Virtualisierung (VT-d) deaktiviert wird](https://www.mdsec.co.uk/2026/03/disabling-security-features-in-a-locked-bios/) und dadurch diese Gegenmaßnahme unwirksam wird. ### Physisches Auslesen vom TPM Das sieht man auch immer wieder mal auf Konferenzen. Hier liest man wirklich physisch auf der Verbindung vom TPM mit. Also wenn es den Schlüssel überträgt. Das funktioniert anscheinend auch ganz gut (hab ich selbst noch nicht gemacht): Pulse Security hat den [Ablauf sauber dokumentiert](https://pulsesecurity.co.nz/articles/TPM-sniffing), stacksmashing hat es in einem [Video](https://www.youtube.com/watch?v=wTl4vEednkQ) an einem Surface-Gerät demonstriert. Einfacher ist es offenbar bei älteren Geräten, weil die TPMs mittlerweile sehr klein sind. Aber auch hier gibt es Wege. Das Ganze funktioniert natürlich wieder nur im TPM-only-Modus. Mittlerweile gibt es hier allerdings auch schon verschiedenste Gegenmaßnahmen wie Firmware TPMs (fTPM), bei denen der Schlüssel gar nicht mehr über einen Bus übertragen wird, oder Session-/Parameter-Encryption, bei der die Kommunikation mit dem TPM verschlüsselt wird. Ob das greift, hängt bei fTPM an der Hardware und bei Session Encryption daran, ob Bootmanager und Betriebssystem verschlüsselte TPM-Sessions überhaupt nutzen. ## Software-Angriffe Software-Angriffe sind meiner Meinung nach viel spannender. Denn die funktionieren auf dem Gerät und man muss keine spezielle Hardware kaufen und herumschleppen. ### bitpixie bitpixie (CVE-2023-21563) ist die Schwachstelle, die mich nach langer Zeit wieder zu BitLocker zurückgeführt hat. Eine sehr spannende Schwachstelle, die schwer zu beheben ist. Sie wurde zuerst 2022 entdeckt (besteht aber seit 2005), dann gepatcht, dann 2023 öffentlich gemacht und dann auf einem [CCC-Talk](https://media.ccc.de/v/38c3-windows-bitlocker-screwed-without-a-screwdriver) Ende 2024 nochmal demonstriert. Weil der Patch immer noch nicht final war. Ich hab diese Schwachstelle das letzte Mal Ende 2025 ausgenutzt. Auf einem neu installierten Gerät. Wie kann das sein, wenn es doch Patches gibt? Zuerst vielleicht, worum es eigentlich geht: Es gibt eine spezielle Art von Reboot namens „PXE soft reboot“. Das passiert, wenn ein Boot fehlschlägt und dadurch ein Recovery Image geladen wird. In diesem Fall wird der BitLocker-Schlüssel nicht aus dem Speicher gelöscht. Der ursprüngliche Angriff war daher, so einen „PXE soft reboot“ zu provozieren und dann von z. B. einem Linux zu booten und den Schlüssel auszulesen. ![Ablauf von bitpixie: alten Boot Manager per PXE booten, das TPM gibt den VMK frei weil PCR 7 und 11 weiterhin passen, ein PXE soft reboot lässt den VMK im Speicher stehen und ein eigenes Linux liest ihn aus](https://www.vidrasec.com/images/blog/bitlocker-bitpixie-flow.de.webp) Hier gab es mit der Zeit immer mehr Einschränkungen, also es wurde schwieriger, die Schwachstelle auszunutzen. Beispielsweise ist es in gewissen Konfigurationen nicht mehr möglich, von Linux zu booten, sondern nur noch Windows. Dann ist das nächste Problem, dass man in dem Windows eine Schwachstelle ausnutzen muss, um überhaupt eine Command Line zu bekommen. Um das zu machen, muss ich ein veraltetes, anfälliges Windows booten. Daher ist die Gegenmaßnahme hier auch, veraltete Betriebssysteme im Secure Boot zu deaktivieren. Das ist ein komplexer Angriff, die [Details hat Neodyme aufgeschrieben](https://neodyme.io/en/blog/bitlocker_screwed_without_a_screwdriver). Das Problem hier ist aber, dass die Gegenmaßnahme ein Update der Secure-Boot-Schlüssel ist (inkl. Widerruf der alten Schlüssel, siehe [KB5025885](https://support.microsoft.com/help/5025885)). Das muss im UEFI passieren, und das haben nicht alle eingespielt. Daher kann es leicht sein, dass ein neues Gerät mit allen Updates immer noch anfällig ist. Da das Ganze auf PXE-Boot passiert, liegt es auch ein bisschen an den restlichen Einstellungen, etwa ob ein UEFI-Passwort gesetzt ist. Systeme, die PCR Validation Profiles auf `0, 2, 4, 7, 11` gesetzt haben, sind hier auch nicht anfällig. Entscheidend ist dabei **PCR 4**, also die Messung des Boot Managers selbst. Die Windows-Standardkonfiguration misst nur `7, 11`, und PCR 7 bildet lediglich den Secure-Boot-Status ab. Ein alter, verwundbarer, aber weiterhin gültig signierter Boot Manager verändert PCR 7 eben nicht, und genau das nutzt der Downgrade aus. ![PCR 4 misst den Windows Boot Manager und fehlt im Windows-Default, PCR 7 misst nur die Secure-Boot-Policy und PCR 11 die BitLocker Access Control. Empfohlen ist das Profil 0, 2, 4, 7, 11](https://www.vidrasec.com/images/blog/bitlocker-pcr-profile.de.webp) Warum es so lange keinen sauberen Fix gab, hat [Neodyme in einem zweiten Artikel](https://neodyme.io/en/blog/bitlocker_why_no_fix/) erklärt. ### YellowKey Deshalb sind wir hier, oder? Die neueste und coolste Möglichkeit, um BitLocker zu umgehen. Das Spannende daran ist, dass der Angriff so simpel ist. Der „Exploit“ ist eigentlich nur eine simple Datei auf einem USB-Stick. Und natürlich auch, weil er als 0-Day veröffentlicht wurde, mit viel Drama um Microsoft. Außerdem war die Schwachstelle ca. 1 Monat lang offen. Eigentlich ist auch das keine Schwachstelle von BitLocker, sondern vom [Windows Recovery Environment](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-recovery-environment--windows-re--technical-reference), welches per Design auf ein unverschlüsseltes Windows zugreifen darf. Im Recovery Environment gibt es übrigens eine CMD, die aber so konfiguriert ist, dass beim Öffnen der Recovery Key abgefragt wird. ![Das Menü „Advanced options“ des Windows Recovery Environment mit Start-up Repair, Command Prompt und weiteren Reparaturoptionen](https://www.vidrasec.com/images/blog/winre-advanced-options.webp) Das heißt aber, wenn im Recovery Environment auf irgendeine Art und Weise Code Execution möglich ist, kann ich auf die unverschlüsselte Platte zugreifen. ![BitLocker gibt den Schlüssel an das vertraute WinRE frei. Die CMD dort fragt den Recovery Key ab, der Weg über eine Datei am USB-Stick führt ohne Recovery Key zur Admin-Shell und damit zum Vollzugriff auf das entschlüsselte Windows](https://www.vidrasec.com/images/blog/bitlocker-yellowkey-flow.de.webp) Als Gegenmaßnahme konnte man daher das Recovery Environment deaktivieren. Mittlerweile gibt es aber auch einen Patch für das Recovery Environment. Ein Hinweis aus der Praxis: Das WinRE-Image wird nicht immer gemeinsam mit dem Betriebssystem mitgepatcht. Es lohnt sich also, nach dem Patchday zu prüfen, ob das Recovery Environment auf den Geräten tatsächlich aktuell ist (`reagentc /info`), statt sich darauf zu verlassen, dass „Windows ist aktuell“ auch „WinRE ist aktuell“ bedeutet. ## Gegenmaßnahmen Wir sehen, die meisten Angriffe zielen gar nicht auf BitLocker selbst ab, sondern auf andere Komponenten. BitLocker schränkt die Angriffsfläche ziemlich ein, diese Angriffe finden dann zum Beispiel einen Umweg über das Recovery Environment, direktes Mitlesen auf der Hardware oder DMA. Es gibt eine Gegenmaßnahme, die bisher noch gegen fast alle Angriffe geschützt hat: Pre-Boot-Authentication. Also BitLocker mit TPM und PIN. Damit schränkt man nämlich die Angriffsfläche noch mehr ein. Es kommt sofort eine Passworteingabe, nicht erst später (wie bei TPM-only der Windows-Login). Natürlich gibt es noch Evil-Maid-Angriffe und der [$5 Schraubenschlüssel](https://xkcd.com/538/) wird bei den meisten auch funktionieren, aber das ist die beste Verteidigung, die wir haben. Deshalb empfehle ich für wichtige Geräte immer TPM mit PIN. Risiko ist aber immer eine Abwägung: Für viele Geräte ist TPM-only meiner Meinung nach auch ausreichend. Dann muss ich es aber richtig konfigurieren: 1. Secure Boot aktiv und ein UEFI-Passwort. Außerdem müssen die Secure-Boot-Zertifikate aktuell sein ([KB5036210](https://support.microsoft.com/help/5036210) und [KB5025885](https://support.microsoft.com/help/5025885)), prüfen lässt sich das mit `[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'` 2. Boot-Reihenfolge im UEFI fixieren: Boot von USB und Netzwerk (PXE) deaktivieren und das Boot-Menü hinter dem UEFI-Passwort sperren. bitpixie braucht den Boot von einem externen Medium oder PXE. Das allein reicht als Schutz nicht aus, aber es hebt die Einstiegshürde deutlich. 3. „Virtualization Based Security“ aktiv (es muss auch verifiziert werden, ob die Einstellung tatsächlich aktiv ist): `systeminfo | findstr /I "Virtualization-based security"` (funktioniert nur in englischem Windows!) 4. PCR Validation Profiles: 0, 2, 4, 7, 11 (`manage-bde -protectors -get C:`) 5. Updates installieren (generell), und dabei explizit das WinRE-Image mitdenken ![Dieselben fünf Komponenten wie bei der Angriffsfläche, jetzt mit den Gegenmaßnahmen: TPM plus PIN deckt alle fünf ab, darunter die Härtung für den Fall, dass TPM only bleiben muss](https://www.vidrasec.com/images/blog/bitlocker-hardening.de.webp) Microsoft hat die [Gegenmaßnahmen auch selbst dokumentiert](https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/countermeasures). ## Fazit Meiner Meinung nach: BitLocker mit TPM und PIN lässt ruhig schlafen. Ich habe das aktiv (inkl. der Gegenmaßnahmen oben) und wenn mir heute mein Notebook gestohlen wird, dann ärgere ich mich, kauf mir ein neues und das war’s. Ich hab keine Angst, dass jemand meine Daten stehlen kann. Bei TPM-only ist das leider nicht so. Mit einer guten Konfiguration bin ich zwar relativ gut geschützt, bitpixie funktioniert zum Beispiel nicht, wenn das PCR Validation Profile auf 0, 2, 4, 7, 11 gesetzt ist. Also wenn ich TPM-only einsetze, ist eine gute Konfiguration unerlässlich. Aber wirklich ruhig schlafen kann ich nur mit Pre-Boot-Authentication. Wenn du bei BitLocker gerade erst anfängst: Die Einrichtung inklusive Anbindung an Active Directory und Entra ID habe ich in [BitLocker absichern: Initiales Setup](/de/blog/setup-bitlocker/) beschrieben, bitpixie im Detail in [BitLocker umgehen ohne Schraubenzieher](/de/blog/bitlocker-bitpixie/). ## Wie sicher ist dein Standardclient wirklich? Die BitLocker-Konfiguration ist einer der Standard-Checks, die ich im Rahmen eines [Internen IT-Infrastruktur-Penetrationstests](/de/services/internal-it-infrastructure-penetration-test/) gegen dein Windows-Standardimage durchführe: PCR-Profile, Secure-Boot-Stand, VBS, Zustand des Recovery Environments und die Frage, wer eigentlich deine Recovery Keys auslesen darf. Dazu kommen Themen wie das [Auslesen von Credentials aus dem Speicher](/de/blog/dump-hashes-in-windows-11-24h2/). Weißt du, in welchem Modus BitLocker auf deinen Geräten tatsächlich läuft, und ob die Konfiguration einer bösartigen Person standhält, die mit dem gestohlenen Notebook nach Hause fährt? Genau das prüfe ich. Du überlegst noch, welcher Scope der richtige ist? Die [Checkliste zur Wahl eines Pentest-Anbieters](/de/blog/pentest-provider-checklist-dach-smb/) hilft dir bei der Einschätzung. [**Fragen zu BitLocker, Windows-Clients oder Pentests? Kontaktiere mich hier.**](/de/contact/) [^dmaoem]: Details zu den Hardware-Voraussetzungen: