Die in Windows mitgelieferte Bitlocker-Verschlüsselung lässt sich aushebeln. Ein als "Bitskrieg" bezeichneter Angriff ermöglicht den Zugriff auf verschlüsselte Volume, wenn ein lokaler Zugang besteht. Der Entdecker hat die Details jetzt offengelegt, nachdem die Nachricht zu "Bitskrieg" vor einigen Tagen die Runde macht.
Kurzer Rückblick auf die Bitskrieg-Ankündigung
Zwischen Microsoft und der Community der Sicherheitsforscher herrscht ein etwas angespanntes Verhältnis. Hintergrund ist, dass das Microsoft Security Response Center Meldungen zu Schwachstellen oft verschleppt, oder die Melder stiefmütterlich behandelt. Rückmeldungen an die Melder, dass es keine Schwachstelle sei, das Ganze aber heimlich gefixt wird, keine Erwähnung der Melder oder nicht gewährte Bug Bounty-Prämien haben dazu geführt, dass einige Sicherheitsforscher nichts mehr an Microsoft melden.
Eskaliert ist das Ganze dann mit einem Sicherheitsforscher mit dem Alias Nightmare Eclipse, der sich von Microsoft über den Tisch gezogen fühlte und im März 2026 eine Windows 0-Day-Schwachstelle mit dem Namen "BlueHammer" veröffentlichte (siehe meinen Blog-Beitrag BlueHammer: Windows 0-day-Schwachstelle). Seit dem hat dieser Sicherheitsforscher sechs Schwachstellen mit Exploits in Microsoft öffentlich gemacht und Microsoft vorgeführt.
Eine der weiteren 0-day-Schwachstellen war YellowKey in der Bitlocker-Verschlüsselung (siehe Chaotic Eclipse zwei 0-Day-Windows Schwachstellen (YellowKey, GreenPlasma), eine in MS Teams). Microsoft hat diese Schwachstelle inzwischen geschlossen, war Nightmare Eclipse aber vor, durch die Veröffentlichung unverantwortlich zu handeln und sperrte dem Sicherheitsforscher den GitHub-Zugang.
Statt zu deeskalieren, goss Redmond weiteres Öl ins Feuer und versuchte allgemein alle Sicherheitsforscher die Schwachstellen ohne vorherige Meldungen veröffentlichen, zu kriminalisieren. Gleichzeitig wurde Druck auf Nightmare Eclipse aufgebaut – für diese Person scheint es wohl "existenzbedrohend" zu sein. Die Eskalation lässt sich über die am Artikelende verlinkten Blog-Beiträge nachlesen.
Diese Entwicklung führte zu einer Solidarisierung der Community der Sicherheitsforscher mit Nightmare Eclipse. Andere Sicherheitsforscher haben gefundene Schwachstellen kostenlos mit dem Sicherheitsforscher geteilt. Dazu gehört auch eine "Bitskrieg" genannte Schwachstelle zum Aushebeln der Bitlocker-Verschlüsselung. Ein Sicherheitsforscher hat die von Nightmare Eclipse mit YellowKey beschriebene Angriffsmethode, kurz nachdem Microsoft diese Schwachstelle schloss, modifiziert und bezeichnet das ganze als "Bitskrieg". Ich hatte das im Beitrag Microsoft versus Nightmare Eclipse: Wir haben jetzt "Bitskrieg" thematisiert. Aber es lagen keine Details zur Schwachstelle vor.
Zum Wochenende hatte ich im Beitrag BlackHat 2026 in Vegas: Tritt das MSRC gerade in das nächste Fettnäpfchen? den Sachverhalt aufgegriffen, dass das Microsoft Security Resource Center von Sicherheitsforschern, die auf der BlackHat 2026 Vorträge halten, wissen will, ob dort Schwachstellen in Microsoft Produkten behandelt werden. Die Vortragenden sollen melden, ob Microsoft informiert sei, und auch die MSRC Meldungsnummer mitteilen. Stößt der Community der Sicherheitsforscher sauer auf, so mein Eindruck.
Details zu Bitskrieg veröffentlicht
Zu obigem Blog-Beitrag hat sich Blog-Leser peter0815 in diesem Kommentar gemeldet, und darauf hingewiesen, dass der Entdecker der "Bitskrieg"-Schwachstelle jetzt auf X die Details im Post Breaking Bitlocker again veröffentlicht hat.
Der Sicherheitsforscher schreibt, dass Microsoft zwar die in YellowKey ausgenutzte Schwachstelle beseitigt habe (eine Datei zur Ausnutzung in WinRE wurde gelöscht). Aber am grundsätzlichen Designproblem habe Microsoft nichts geändert.
Der Angriff auf die Bitlocker-Verschlüsselung kann über die Wiederherstellungsumgebung (Windows Recovery Environment, WinRE) von Windows erfolgen. WinRE ist auf einer Systempartition gespeichert, die unverschlüsselt ist. Und das Trusted Platform Module (TPM) wird zum Zugriff erst gesperrt, wenn man eine Funktion nutzt, die nicht zur Startreparatur gehört. Die Überlegung ist daher, dass man unter WinRE Code auszuführen versucht. Ist der Zugriff auf das TPM noch nicht gesperrt, hat man Zugriff auf das verschlüsselte Bitlocker-Laufwerk.
In seiner Offenlegung auf X beschreibt Jonas Lyk, wie er ein Windows 11 in einer virtuellen Maschine installierte. Normalerweise wird ein Bitlocker Recovery-Key in WinRE abgefragt, wenn die Maschine in das Recovery Environment gebootet wird. Der Zugriff auf die Bitlocker-Laufwerke ist also für Dritte gesperrt. In dieses Stadium trägt der Sicherheitsforscher mit folgenden BCDEdit-Befehlen:
bcdedit /set ems 1 bcdedit /set emsport 1
Anweisungen im Windows Boot Configuration Data (BCD) Bereich ein, die einen Emergency Management Services Port (EMSPORT ) zur seriellen Kommunikation mit Windows über einen Port für das Remote Management öffnen. Dann kann zur Boot-Zeit auf dem Host mittels Putty über eine Pipe mit der Windows Wiederherstellungsumgebung kommuniziert werden.
In der Offenlegung ist beschrieben, wie über Putty mittels diverser Befehle dann der Zugriff auf das Bitlocker-Volumen freigeschaltet werden kann. Das funktioniert, da TPM die Ausführungssequenz hasht, bevor der Anmeldebildschirm erscheint. Nur wenn sich diese Ausführungssequenz nicht geändert hat, wird das Laufwerk entsperrt. Der Angriff funktioniert für alle Windows-Version ab Windows XP und kann auch auf physischen Maschinen mittels eines USB-Serial-Adapters durchgeführt werden. Diese Aussage des Entdeckers in einem Tweet ist so zu interpretieren, dass diese für das Konzept "Ausnutzung der Wiederherstellungsumgebung" gilt. Die Bitlocker-Verschlüsselung wurde 2006 von Microsoft vorgestellt und 2007 erstmals bei Windows Vista genutzt. TMP 1.2 wird seit Windows 8.0 und Linux Kernel 4.0 unterstützt.
Einordnung des Ganzen
Relevant erscheint mir der obige Ansatz nur für Systeme ab Windows 10 aufwärts, auf denen Bitlocker zur Verschlüsselung vertraulicher oder sensibler Daten abgelegt werden. Allerdings sehe ich derzeit die Auswirkungen als begrenzt an. Der Angreifer müsste Zugriff auf einen Rechner mit Windows 10 oder 11 haben, um diesen in den Wiederherstellungsmodus zu zwingen und die skizzierten Manipulationen vorzunehmen. Es gab in der Vergangenheit immer wieder Ansätze, Bitlocker auszuhebeln – jetzt ist es etwas leichter geworden.
Relevant könnte dies für Notebooks oder Systeme werden, die verloren, gestohlen, beschlagnahmt oder bei einem Angriff vor Ort manipuliert werden sollen. Strafverfolger und Angreifer haben ggf. einen einfacheren Ansatz, an verschlüsselte Bitlocker-Daten heranzukommen. Aber eine breite Ausnutzung sehe ich nicht – bei einem Remote-Angriff auf ein laufendes Windows sind die Bitlocker-Volumes eh im Zugriff des Betriebssystems.
Was ist derzeit final nicht abschätzen kann, ist das Risiko für Windows-Systeme in der Cloud, die virtualisiert laufen und mit Bitlocker-Volumes arbeiten. Erhält ein Angreifer Zugriff auf den Host, kann er das obige Szenario für einen Bitlocker-Angriff nutzen. Aber dies sollte bemerkt werden, da dazu die VM mit dem Gastbetriebssystem in den Wiederherstellungsmodus gezwungen werden. Alles in allem ein gewisser Aufwand, den man kaum treibt, wenn es einfachere Möglichkeiten gibt, an die Daten heran zu kommen.
Die Quintessenz aus diversen Vorfällen der letzten Jahre ist imho, dass Bitlocker nicht als sicher im Hinblick auf die Verschlüsselung vertraulicher Daten angesehen werden kann. Im Beitrag Microsoft muss Bitlocker-Key an US-Strafverfolger (FBI) übergeben hatte ich ja bereits erwähnt, dass ein gespeicherter Bitlocker Recovery-Key durch Microsoft an Strafverfolger übergeben werden muss. Fazit: Mit dem obigen Szenario ist Bitlocker nicht pulverisiert – und mein Gefühl ist, dass Microsoft da auch wenig ändern wird – aber es zeigt auch, wie man gezielt Design-Schwächen ausnutzen kann. Von daher stufe ich das Ganze als "lästig" für Microsoft, im Hinblick auf dieses "Enterprice grade"-Feature, ein. Mal schauen, was noch ans Licht kommt.
Ähnliche Artikel:
BlueHammer: Windows 0-day-Schwachstelle
BlueHammer-Nachlese: Defender-Patch vom 14.4.2026 und Analyse von Fortra
RedSun: Nächste Windows Defender 0-Day-Schwachstelle
Chaotic Eclipse zwei 0-Day-Windows Schwachstellen (YellowKey, GreenPlasma), eine in MS Teams
Nightmare Eclipse veröffentlicht MiniPlasma-Schwachstelle CVE-2020-17103
Zoff und Schwarze-Peter-Spiel zwischen 'Microslop' und Chaotic Eclipse
Nightmare Eclipse auf GitLab gebannt; Microsoft nimmt Stellung
Microsoft versus Nightmare Eclipse: Wir haben jetzt "Bitskrieg"
BlackHat 2026 in Vegas: Tritt das MSRC gerade in das nächste Fettnäpfchen?
MVP: 2013 – 2016
Der grundsätzliche Irrtum ist doch zu glauben, das Bitlocker & TPM dem Schutz des Users diene! Dazu muss man sich nur die Entstehungsgeschichte (und die treibende Kräfte dahinter) ansehen und zwar von den Anfängen an ( Palladium & Co)
Soweit ich mich erinnere war die Entstehungsgeschichte "Microsoft will uns nur noch erlaubte Software ausführen lassen!1!11!" Obwohl die Idee überhaupt nicht (nur) von Microsoft kam. Das ist jetzt knapp 25 Jahre her.
BitLocker und TPM dienen ausschließlich dem Schutz des Nutzers denn etwas Anderes ist damit überhaupt nicht möglich. Worauf du vermutlich raus willst ist SecureBoot was übrigens auch nicht von MS kam sondern von Android/iOS geklaut und zuerst auf Intel Macs verwendet wurde – unter anderem Namen natürlich wegen kleiner Penis und so – was aber gerne unter den Teppich gekehrt wird weil nur Microsoft der Feind ist.
Bei SB gibt es für alternative Systeme den kleinen sehr einfachen aber signierten Shim Bootloader der, wie auch das System zur Verhinderung von Schadsoftware zur Bootzeit zusammen mit der Open Source Gemeinde entwickelt wurde.
Würde man anfangen andere unerwünschte Programme zu sperren würde man das Risiko eingehen auf Grund von Kartellrecht kaputt geklagt werden. Selbst in den USA wo alles was möglicherweise den freien Markt einschränken würde (was auch sonst) empfindliche Strafen nach sich ziehen kann.
Wir sind auf deine fundierten Belege dazu gespannt.
Praktisch jede Erweiterung von ausufernder Telemetrie über Zwangsupdates bis hin Secureboot & Co. dienen zur Bevormundung und sukkzessiver Entmachtung der Benutzer über "ihre" Hardware. Dieser Trend fing mit Vista an und setzt sich beschleunigend bis heute fort. Viele wollen oder können das aber (noch) nicht wahrhaben.
TLDR: Strukturell kaputt
Sogesehen nichts Neues für und von Microsoft. Und die Art und Weise im Umgang damit erstaunt auch nicht sonderlich.
Aber wer bin ich schon… ich bin nur ein Depp, der seit Jahrzehnten mit LUKS, Clevis und Tang umgeht…
Wieder nix bei Pre-Boot PIN wie schon seit Jahren ausdrücklich empfohlen. Nur TPM Auto-Entsperrung und Hinweis, das es nicht gesperrt wird. Wodurch auch? Schon hier hätte man sich die Frage stellen müssen wie das TPM überhaupt erst entsperrt wurde und warum die WinRE Partition nicht verschlüsselt ist habe ich vor einigen Tagen schon erklärt war aber scheinbar nicht so wichtig.
Nur lokal? War bei den kürzlichen Linux Lücken dann nämlich kein Problem mehr. Wahrscheinlich weil dort ohne SecureBoot bei lokalem Zugriff jeder schädliche Code auch ohne Sicherheitslücken geladen werden kann (Och jetzt wird der Kommentar bestimmt wieder direkt gelöscht).
Könnte man Code ohne TPM Lock ausführen hätte man Zugriff auf das verschlüsselte Laufwerk? Nö, man hätte Zugriff auf das bereits automatisch entschlüsselte Laufwerk. Dann könnte man die Daten aber ggf. auch an einem Bus abgreifen.
Microsoft hat die darunterliegende Design Schwäche nicht behoben? Wie auch? Die sind nicht für die TPM-Spezifikationen verantwortlich und wie sollte man sowas auch beheben? Falls es sich überhaupt um eine entsprechende Schwäche handelt und mit BitLocker hat das auch nichts zu tun. Selbes "Problem" existiert auch bei jedem anderen OS, welches TPM Schlüssel für die Verschlüsselung nutzt.
Wenn der Bitlocker Recovery-Key in WinRE abgefragt werden würde, wenn die Maschine in das Recovery Environment gebootet wird wie beschrieben wäre das Problem auch nicht vorhanden. Abgesehen davon ist das nicht der Sinn des Recovery Passworts, welches auch nichts mit dem TPM zu tun hat. Man könnte hier in zukünftigen Versionen zwangsweise ein Passwort z.B. eines Admins oder des Hauptbenutzers abfragen und ältere Ausgaben sperren oder einfach eine verdammte TPM-PIN konfigurieren!
Der Angriff funktioniert für alle Windows-Version ab Windows XP obwohl BitLocker erst ab Vista vorhanden ist und man unter XP nur Sticks per EXE Datei entschlüsselt einhängen kann? Beeindruckend…
Die Übergabe an Ermittlungsbehörden nennt sich im Idealfall Rechtsstaat und hat weder was mit diesem Thema noch mit der Verschlüsselung zu tun außer das beides dieselben nicht vorhandenen Zusammenhänge versucht herzustellen!
Aus dem how-to:
Rollback um die geschlossene Lücke wieder zu öffnen? Nicht wenn der Zustand signiert ist!
Welches ISO? Bei der vom Screenshot geht der angeblich verwendete Befehl für den lokalen Account nämlich nicht mehr!
Sicherheitsfunktionen ohne Zusammenhang zu BitLocker betont eingeschaltet, Andere (nützliche?) aus.
Zusammenfassend: Zum x-ten Mal, wie übrigens bei den vorangegangenen "Lücken" auch, dieselbe TPM Designschwäche (wenn überhaupt) ohne auch nur den kleinsten Zusammenhang zur eigentlichen BitLocker Verschlüsselung ausgenutzt. "Breaking BitLocker again" ist schlicht (doppelt) gelogen oder zeugt von nicht einmal grundlegendem Verständnis für auch nur einen kleinen Teil des Sachverhalts!
Noch ein paar Zahlen: Jedes Jahr liefern etwa 5-600 Entitäten Lücken an Microsoft. Einer heult, eine handvoll schließt sich an und starten einen "Krieg" gegen MS. Macht etwa 99% problemlose Fälle trotzdem ist natürlich klar wer Schuld hat.
Wieso ist das eigentlich existenzbedrohend wenn man angeblich alles richtig gemacht habe?
Vielleicht sollte man geistigen Kindern (s.a. der tolle zusammenhanglose Name) mal ein paar Jahre Computerverbot verordnen
Der heißt übrigens Jonas Lykkegård und nicht Jonas Lyk
Alles in allem fehlt mir hier – vorsichtig ausgedrückt – jeglicher Anspruch an irgendwelche Standards! Und den "Freund" von dem die Lücke angeblich stammt stelle ich mir folgendermaßen vor: Hey Freund-GPT, wie komme ich an meine Daten bei einem lokalen PC, der zwar mit BitLocker und TPM aber ohne PIN geschützt ist und momentan der Zugriff auf die entsprechenden Zugangsdaten nicht möglich ist?
100% Zustimmung. Aber hier läufst Du mit differenzierter Faktenbetrachtung gegen die Wand. Ich hatte BL immer mit Boot-PIN und weiteren nützlichen GPO-Parametern an den Start gebracht, nie (Sicherheits)-Probleme. Es liegt hier an der kruden Mischung von gestandenen Admins und, anderseits Hobby-Usern und Verschwörungstheoretikern. Mag sein, dass mal Privatrechner irgendwann von irgendwas betroffen waren, ich nehme das zur Kenntnis, aber unverwaltete Rechner sind nicht meine Baustelle.
Ich würde euren Spin mal gerne auf eine andere Ebene lenken (nicht als Kritik verstehen, eure Argumente sind ja nicht von der Hand zu weisen). Warum stelle ich solche Artikel hier im Blog ein? Der erste Reflex von einigen Leuten ist doch "Born will Microsoft bashen". Da gilt "was juckt den Elefanten, wenn ein Floh ihn am Schwanz zieht?". Der Hintergrund ist, zu zeigen: "Da gibt es was, schaut genauer hin, überlegt, ob es euch tangiert und was ihr machen könnt." Es ist ein Informationsangebot – die Originalquellen sind verlinkt. Jetzt könnte man prüfen: "Bin ich betroffen? Nein, weil … und zur Tagesordnung übergeben".
Klar kann man über die Mischung von "gestandenen Admins und, anderseits Hobby-Usern und Verschwörungstheoretikern" schwadronieren. Der gestandene Praktiker filtert heraus, was für ihn relevant an, und hält es ansonsten mit dem oben erwähnten Elefanten (habe ich jedenfalls in meiner Zeit in der Industrie so gehandhabt).
Es nützt nichts, über die Welt da draußen zu schwadronieren und seine ideale Konstellation als Maßstab zu nehmen, führt imho an der Lebenswirklichkeit vorbei. Andernfalls könnte ich den Blog hier schließen – da keine Sicherheitsvorfälle mehr, keine Bugs mehr und sonst auch wenig los.
Das Rausfiltern von dem Kokolores kostet aber Zeit und Aufreger! Und da noch nicht mal sichergestellt, dass sich unter einem Kommentatorname immer die gleiche Person versteckt, siehe oben 2x "Anonym", die sich absolut wiedersprechen, kann man noch nicht mal überspringen, wenn man bestimmte Namen liest. Oder man lässt das mit dem Lesen der Kommentare gleich ganz sein. Und das hat auch für Sie Auswirkungen, denn je weniger Beteiligung, destwo weniger wird geschaltete Werbung abgerufen, usw.
Ich bin mal gespannt, ob Microsoft am Patchday morgen etwas dagegen unternimmt.
Einerseits ist die Zeit sehr knapp (die Preview-Updates sind längst durch), andererseits sollten sie (wenn die Unterstellung einer absichtlich eingebauten Lücke stimmt) ohnehin genug Informationen gehabt haben.
Ich denke, sie können und wollen nichts zum Patchday unternehmen. Es gibt maximal eine Empfehlung, dieses und jenes zu beachten.
Am Wochenende bin ich auf administrator.de auf den Post Der Butler hat die Schlüssel: Kann man Produkten vertrauen, … gestoßen. Ging zwar dort um OpenClaw und den Einsatz durch große US-IT-Anbieter (Meta, Microsoft Scout, etc.). Aber mir ging sofort "die BL-Wiederherstellungsschlüssel liegen bei MS vor" durch den Kopf.
"Der Angriff funktioniert für alle Windows-Version ab Windows XP "
Bitlocker wurde aber erst mit Vista Enterprise/Ultimate eingeführt. Müsste der Betreiber des Vista-Blogs eigentlich wissen.
Und dann noch etwas. Also man muss im WinRE in der Konsole mit bcdedit etwas ändern, und dann Windows normal booten, bis etwa zum Anmeldescreen warten und kann dann über eine serielle Konsole was machen? Aber zu dem Zeitpunkt ist Windows doch schon von der verschlüsselten Partition gestartet? Wo ist da jetzt der Angriff notwendig? Man muss sich ja doch nur noch anmelden… Irgendwie verstehe ich jetzt den Witz an der Sache noch nicht. Muss wohl noch andere Veröffentlichungen zu dem Angriff lesen, um es zu verstehen.
Aber wenn ich es bisher richtig verstehe, würde auch hier ein Bitlocker PIN den Angriff ins Leere laufen lassen, weil man erst garnicht mehr so weit kommt. Oder man schaltet das WinRE einfach ganz ab, braucht im Enterprise eh kaum einer, defekte Installationen werden da nicht repariert sondern geplättet und neu aufgesetzt, geht schneller als alle Reparaturversuche.
Nö, du bist einer der Wenigen, die es kapiert haben!
Abgesehen davon ist WinRE ist eher für Privat oder KMU wo ggf. noch Daten gerettet werden müssen oder eine Reparatur schneller geht als alles manuell neu zu machen weil keine Softwareverteilung existiert.
Deine Aussage stimmt, wenn du davon ausgehst, das es integriert ist.
Laufen tut es auch unter XP als „BitLocker to Go". Somit kann es auch dort zum Zugriff auf den Schlüssel genutzt werden.
Ich denke, dass es auch so gemeint ist.
Bitlocker-to-Go ist nur für USB-Sticks und andere externe Datenträger, aber nicht fürs Bootlaufwerk. Das ist unter XP immer unverschlüsselt, es sei denn jemand legt Veracrypt drunter.
V.a. ohne Schlüssel sondern nur mit Passwort, oder?
Interessant wie viel hier geschrieben und doch nicht verstanden wird.
An die Daten eines mit Bitlocker verschlüsselten Rechners kommst Du "normalerweise" nicht dran.
Du kannst aber im WinRE Einstellungen setzen um einen seriellen Zugang während des Starts von Windows zu ermöglichen.
Während des Starts kann über dieses seriellen Zugang der nötige Schlüssel extrahiert werden. Dieser kann nun verwendet werden um das Dateisystem an einem anderen Gerät einzuhängen.
Ist schon eine Designfrage wie MS das hier angeht. Ohne eine PBA wird das vermutlich kaum zu lösen sein.
Die Schlüssel befinden sich im TPM und das die extrahiert und an einem anderen Rechner verwendet werden können – wie sollen die dort überhaupt ins andere TPM kommen – geht aus der Beschreibung nicht hervor. Man könnte als Admin ggf. den Recovery Key auslesen aber wozu? Die Daten sind zu dem Zeitpunkt bereits entschlüsselt weil das TPM gemäß Einstellung die Entschlüsselung bzw. Freigabe der entsprechenden Schlüssel autorisiert hat. Da ist dein Denkfehler: Die Daten sind eben nicht mehr verschlüsselt!
Ok, erst frug ich mich das selbe wie Froschi, aber wenn man dann den Bitlocker Key hat, Platte ausbauen und auslesen, das macht dann tatsächlich Sinn, sogar mit gesetztem Pin. Evtl. kann man aber an der seriellen Konsole die Platte auch mit Robocopy auf ein Netzlaufwerk oder USB-Stick/Plättchen kopieren, ohne sich am Windows Loginscreen anmelden zu können. Hilft derzeit wohl nur WinRE abzuschalten.
Ich kanns nicht oft genug sagen:
Das wäre bei deaktivierten WinRE nicht passiert :)
Habe die WinRE noch nie verstanden, wofür man die brauchen sollte… man installiert sein System testet es und zieht sich dann ein Golden Master.
Wenn irgendwas schief läuft ist das schneller wieder eingespielt als das mein sein System mit WinRE wieder geradegebogen hat.
Imagen, ja, kann man, die wenigsten Endbenutzer werden das machen, fehlt das Wissen, Erfahrung und die werden auch vor der Recovery-Konsole stehen, wie der Ochs vorm Berg.
Für jemand, der damit umgehen kann, oftmals eine Rettungsoption, habe schon mehrfach gescheiterte MBR->GPT-Konvertierungen damit wieder startfähig gemacht, auch Dateisystem daraus zu checken und korrigieren löst so manches Bootproblem.
Das kann man aber durchaus auch mit einem boot vom Stick. Ganz ohne WinRE.
Gehe ich recht in der Annahme, dass Nicht-System-Platten, deren Bitlocker unabhängig vom TPM per Extra-Kennwort entsperrt wird, von "Bitskrieg" nicht betroffen sind, so lange niemand "automatisch entsperren" aktiviert?
Frage an das Schwarmwissen:
Reicht es, wenn ich "reagentc /disable" ausführe, um WinRE sicher zu deaktivieren, oder sollte ich mehr tun? irgendwas von der Platte putzen?
Bitlocker mit Startup-Pin ist nicht betroffen, weil der IMMER abgefragt wird. Da geht nichts automagisch.
Ja: "reagentc /disable" und das Tor zur Hölle ist geschlossen.
Ich bevorzuge jedoch bei jedem Systemstart den Befehl abzusetzen. Kann ja glatt einer bei MS auf die Idee kommen, dass mans wieder aufdreht und das will ich nicht :)
@Markus K
FYI
Nightmare Eclipse behauptet, er habe einen Weg, um auch bei gesetzter PIN ranzukommen (aber diesen absichtlich nicht veröffentlicht), ebenso mutmaßt er, dass sein Exploit auch bei deaktiviertem WinRE funktionieren könnte, wenn bestimmte Randumstände gegeben sind (Windows Update). Beides steht schon lange in seinem Blogspot.
You can boot from own USB, so there is no way to any configuration disabling.
And pin cant solve nothing. Because is not used for encryption itself. If you use veracrypt, key is encrypted by password. But if you use bitlocker and pin, it's only SW check … like je or jne instruction. So it can be easily bypassed.
"reagentc /disable" hat offenbar bewirkt, dass ich nun bei jedem Start den Recovery-Key eingeben darf.
Ist wohl sicher, aber sehr nervig.
Aktuell nutzen wir BitLocker ausschließlich ohne PIN. Eine Option dafür wurde aber bereits vorgeschlagen: https://roadmap.synaxon-services.de/p/skript-bitlocker-aktivieren-um-optionalen-parameter-fur-pin-erweitern.
Den Pin aktivierst du per Gruppenrichtlinie oder einem zentralen Bitlocker-Management.
Kannst du zentrale BitLocker Management-Tools empfehlen, Froschkönig?
Bin zwar nicht Froschi, aber: Viele Enterprise-Antivrus können das. Du kannst es auch aus Intune steuern.