Reicht Secure Boot, um BlackLotus zu stoppen?

Allein nicht. BlackLotus nutzt einen älteren, gültig signierten Windows-Start-Manager aus, dem Secure Boot weiterhin vertraut. Das Patchen allein ersetzt den Start-Manager auf dem Datenträger, hindert einen Angreifer aber nicht daran, den alten, verwundbaren mitzubringen. Die Lösung ist die Sperrung: Das alte Signaturzertifikat wird in die DBX aufgenommen, sodass die Firmware damit signierte Start-Manager ablehnt, nachdem das Gerät auf einen mit Windows UEFI CA 2023 signierten Start-Manager umgestellt wurde.

Was passiert, wenn die Microsoft-Secure-Boot-Zertifikate von 2011 ablaufen?

Geräte starten weiter; UEFI-Firmware prüft beim Validieren von Startkomponenten im Allgemeinen nicht das Ablaufdatum von Zertifikaten. Das Problem ist die Wartung: Nach dem Ablauf kann Microsoft mit den alten Zertifikaten keine neuen Start-Manager, DB- und DBX-Updates mehr signieren, sodass Geräte, die die 2023-Zertifikate nie erhalten haben, keine Sicherheitskorrekturen für die Startkette mehr bekommen. Erst die Umstellung jedes Geräts auf die KEK- und DB-Zertifikate von 2023 hält sie wartbar.

Lösen die Secure-Boot-Updates eine BitLocker-Wiederherstellung aus?

Meist nicht, wenn Windows sie anwendet und BitLocker die PCR-7-Bindung nutzt, denn Windows erwartet die Änderung und versiegelt den Schlüssel neu. Eine Wiederherstellung kann auf Geräten mit einem PCR-Profil ohne PCR 7, bei mancher Firmware oder bei Änderungen außerhalb von Windows auftreten. Stellen Sie sicher, dass jeder Wiederherstellungsschlüssel hinterlegt ist, und testen Sie jedes Hardwaremodell in einem Pilotring vor der breiten Bereitstellung.

Secure Boot, UEFI und die BlackLotus-Gegenmaßnahmen

Alles, was Windows zu seinem eigenen Schutz tut, von BitLocker bis Credential Guard, setzt voraus, dass der vor Windows ausgeführte Code vertrauenswürdig war. Secure Boot erzwingt diese Annahme: UEFI-Firmware führt nur Startkomponenten aus, die mit Schlüsseln aus ihrer Signaturdatenbank signiert sind. Bootkits wie BlackLotus haben gezeigt, dass „Secure Boot ist aktiv“ nicht dasselbe ist wie „die Startkette ist sicher“, und die Microsoft-Zertifikate, die das ganze System verankern, werden gerade ersetzt.

Der Leitfaden zur BitLocker-Härtung prüft, dass Secure Boot aktiv ist. Dieser Leitfaden geht tiefer: die Schlüsseldatenbanken, die Gegenmaßnahmen zu CVE-2023-24932, der Übergang auf die Zertifikate von 2023 und die Härtung der Firmware. Er gehört zur Reihe BitLocker & Startsicherheit.

Wie Secure Boot entscheidet, was ausgeführt wird

Variable	Inhalt	Wer sie aktualisiert
PK (Platform Key)	Der Schlüssel des OEM; Eigentümer der Plattform	OEM-Firmware
KEK (Key Exchange Key)	Schlüssel, die DB und DBX aktualisieren dürfen, einschließlich des KEK von Microsoft	OEM oder mit dem PK signierte Updates
DB (zugelassene Signaturen)	Zertifikate und Hashes vertrauenswürdigen Startcodes: Microsofts Windows-CA, Microsofts UEFI-CA für Drittanbieter	Mit einem KEK signierte Updates
DBX (verbotene Signaturen)	Gesperrte Zertifikate und Hashes bekannter verwundbarer Startcodes	Mit einem KEK signierte Updates

Die Firmware führt eine Startkomponente nur aus, wenn deren Signatur auf die DB zurückführt und sie nicht in der DBX steht. Windows-Start-Manager wurden mit Microsoft Windows Production PCA 2011 signiert; Linux-Shims und viele Option-ROMs führen auf Microsoft Corporation UEFI CA 2011 zurück; Microsofts DB- und DBX-Updates sind mit Microsoft Corporation KEK CA 2011 signiert.

Warum BlackLotus die Regeln geändert hat

BlackLotus (CVE-2022-21894, gefolgt von CVE-2023-24932) missbraucht einen Start-Manager, der alt, aber vom PCA-2011-Zertifikat gültig signiert ist. Secure Boot führt ihn anstandslos aus, und der Angreifer nutzt dessen Schwachstelle, um Schutzmechanismen abzuschalten und ein unsigniertes Bootkit zu laden, das unterhalb des Betriebssystems persistiert, selbst wenn BitLocker im Einsatz ist.

Das Patchen von Windows ersetzt den Start-Manager auf der EFI-Systempartition, doch ein Angreifer mit Adminrechten kann den alten, verwundbaren zurückkopieren. Die einzige dauerhafte Lösung ist, dem PCA-2011-Zertifikat per DBX das Vertrauen zu entziehen, was wiederum voraussetzt, dass jedes Gerät zuvor einen mit der neuen Windows UEFI CA 2023 signierten Start-Manager startet. Diese Reihenfolge und das Risiko, Startmedien unbrauchbar zu machen, sind der Grund, warum Microsoft die Gegenmaßnahmen optional und gestaffelt gestaltet hat.

Schritt 1: den aktuellen Zustand inventarisieren

Auf jedem Gerät:

PowerShell

Confirm-SecureBootUEFI                         # True = aktiviert; Fehler = Start im Legacy-BIOS/CSM
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes) -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name KEK).Bytes) -match 'KEK 2K CA 2023'

Sammeln Sie diese Werte per Compliance-Skript zusammen mit Modell und Firmwareversion ein (Get-CimInstance Win32_ComputerSystem, Get-CimInstance Win32_BIOS). Geräte, die noch im Legacy-BIOS- oder CSM-Modus starten, müssen zuerst umgestellt werden: mbr2gpt.exe /validate /allowFullOS, dann /convert, anschließend die Firmware auf reines UEFI umstellen und Secure Boot aktivieren.

Intune-Compliancerichtlinien können Secure Boot über Device Health > Require Secure Boot to be enabled on the device verlangen; das stützt sich auf die Attestierung des Measured-Boot-Protokolls statt auf ein Skriptergebnis.

Schritt 2: die Gegenmaßnahmen zu CVE-2023-24932 anwenden

Microsoft dokumentiert das vollständige Verfahren in KB5025885 („How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932“). Lesen Sie vor dem Start die aktuelle Fassung; der Zeitplan für die Erzwingung wurde mehrfach verschoben. Der Mechanismus ist ein Registrierungswert, der Windows mitteilt, welche Secure-Boot-Wartungsschritte bei den nächsten Neustarts auszuführen sind:

Text

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Secureboot
Value: AvailableUpdates  (REG_DWORD)

Zum Zeitpunkt des Schreibens sind folgende Schritte dokumentiert:

Schritt	AvailableUpdates	Wirkung	Bestätigungsereignis (Systemprotokoll, Quelle TPM-WMI)
1	`0x5944`	Die Secure-Boot-Zertifikate von 2023 bereitstellen (Windows UEFI CA 2023 in die DB, dazu gegebenenfalls den KEK von 2023 und die Drittanbieter-CAs) sowie den mit Windows UEFI CA 2023 signierten Start-Manager	1036 (DB aktualisiert)
2	(keiner: prüfen)	Bestätigen, dass `UEFICA2023Status` unter `...\Secureboot\Servicing` den Wert `Updated` hat und der mit 2023 signierte Start-Manager vorhanden ist	1799
3	`0x80`	Windows Production PCA 2011 in die DBX aufnehmen (die Sperrung)	1037
4	`0x200`	Das SVN-Update (Secure Version Number) auf die Firmware anwenden	1042

Windows löscht jedes Bit, sobald es verarbeitet wurde; die Wartungsaufgabe läuft alle 12 Stunden, und einige Schritte brauchen einen oder zwei Neustarts. Führen Sie zuerst die Schritte 1 und 2 breit aus. Gehen Sie erst zu den Schritten 3 und 4 über, wenn alle Startmedien, die das Gerät starten könnten, aktualisiert sind (Schritt 4 unten), denn nach der Sperrung startet nichts mehr, was nur mit PCA 2011 signiert ist. Fehler erscheinen als Ereignisse derselben Quelle: 1795 (die Firmware hat einen Fehler zurückgegeben, meist durch ein OEM-Firmwareupdate behoben), 1796 (unerwarteter Fehler, mit Fehlercode) und 1801 (die neuen Zertifikate wurden noch nicht auf die Firmware angewendet). Ereignis 1808 bestätigt, dass ein Gerät alle erforderlichen neuen Zertifikate besitzt.

Schritt 3: auf die Zertifikate von 2023 umstellen

Die Zertifikate von 2011 laufen 2026 ab: KEK und Drittanbieter-UEFI-CA im Juni, die Windows Production PCA im Oktober. Der Ablauf hindert Geräte nicht am Starten, beendet aber ihre Fähigkeit, neue Secure-Boot-DB/DBX-Updates und neue, unter der alten Kette signierte Start-Manager zu erhalten.

Der Zielzustand für jedes Gerät:

KEK: Microsoft Corporation KEK 2K CA 2023
DB: Windows UEFI CA 2023, dazu Microsoft UEFI CA 2023 und Microsoft Option ROM UEFI CA 2023, wo Drittanbietercode vertraut wird
Start-Manager: signiert mit Windows UEFI CA 2023

Microsoft verteilt diese Updates über die Windows-Wartung und dokumentiert mehrere Wege, sie gezielt bereitzustellen:

Registrierung: AvailableUpdates = 0x5944 unter HKLM\SYSTEM\CurrentControlSet\Control\Secureboot stellt alle benötigten Zertifikate und den mit 2023 signierten Start-Manager bereit. Der Fortschritt wird unter HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\Servicing gemeldet: UEFICA2023Status wechselt von NotStarted über InProgress zu Updated, und UEFICA2023Error ist bei einem Fehler ungleich null. MicrosoftUpdateManagedOptIn = 1 unter dem Schlüssel Secureboot meldet das Gerät stattdessen für Microsofts kontrollierten Feature-Rollout an.
Gruppenrichtlinie: Computer Configuration > Administrative Templates > Windows Components > Secure Boot, einschließlich Enable Secure Boot Certificate Deployment.
Intune-Einstellungskatalog: Enable Secureboot Certificate Updates, Configure Microsoft Update Managed Opt In und Configure High Confidence Opt-Out.

Die Richtlinienoptionen erfordern aktuelle kumulative Updates; prüfen Sie daher in Microsofts aktueller Anleitung zum Update der Secure-Boot-Zertifikate den Mindest-Build für jede Windows-Version.

KEK-Updates müssen mit dem Platform Key des OEM signiert sein, deshalb brauchen manche Modelle ein Firmwareupdate, bevor Windows sie anwenden kann. Verfolgen Sie den Fortschritt pro Modell, nicht nur pro Gerät.

Schritt 4: Startmedien und Wiederherstellungswege aktualisieren

Vor jeder Sperrung:

WinPE und PXE: Startabbilder von Configuration Manager und WDS aus aktuellen Windows-ADK-Medien neu erstellen, damit sie den mit 2023 signierten Start-Manager enthalten.
Installations- und Wiederherstellungs-USB-Laufwerke: aus aktuellen Medien neu erstellen. Microsoft veröffentlicht Anleitungen und Werkzeuge zum Aktualisieren startfähiger Medien.
Windows-Wiederherstellungsumgebung auf jedem Gerät: bestätigen, dass WinRE zusammen mit dem Betriebssystem gewartet wurde.
Virtuelle Maschinen: Hyper-V-VMs der Generation 2, VMware- und Cloud-VMs haben eigene virtuelle Firmware und Vorlagenschlüssel. Prüfen Sie die Anleitung Ihres Hypervisor-Herstellers zu KEK- und DB-Updates und verwenden Sie für Windows-Gäste unter Hyper-V die Secure-Boot-Vorlage Microsoft Windows.

Schritt 5: die Firmware selbst härten

Secure Boot kann im Firmware-Setup von jedem mit physischem Zugriff abgeschaltet werden, sofern die Firmware nicht gesperrt ist:

Einstellung	Wert
Startmodus	Nur UEFI; CSM/Legacy deaktiviert
Secure Boot	Aktiviert, Standardmodus mit Werksschlüsseln (nicht Setup- oder benutzerdefinierter Modus)
Firmware-Administratorkennwort	Gesetzt, eindeutig pro Gerät oder pro Modell, in Ihrem Tresor abgelegt
Start von USB / Netzwerk	Deaktiviert oder hinter dem Firmwarekennwort, wo nicht benötigt
Microsoft-UEFI-CA für Drittanbieter	Auf reinen Windows-Geräten deaktiviert, wo Option-ROMs es zulassen (Secured-core-PCs werden so ausgeliefert)
Thunderbolt / externe DMA-Ports	Auf Kernel DMA Protection setzen; siehe den Leitfaden zu VBS und DMA

Wenden Sie diese Einstellungen mit OEM-Werkzeugen an (alle großen Hersteller bieten Kommandozeilenprogramme zur BIOS-Konfiguration) oder, auf unterstützter und bei Windows Autopilot registrierter Hardware, mit Intune-Profilen für Device Firmware Configuration Interface (DFCI), die Firmwareeinstellungen auch gegen lokale Änderungen sperren können. Halten Sie die Firmware über Windows Update oder den OEM-Kanal aktuell: Viele Secure-Boot-Korrekturen kommen als Firmwareupdates.

Was kaputtgeht

Alte Startmedien funktionieren nach der DBX-Sperrung nicht mehr: USB-Sticks in der Helpdesk-Schublade, PXE-Abbilder, Wiederherstellungsmedien von Backup-Drittanbietern.
Firmwarefehler: Manche Modelle lehnen DB-, KEK- oder DBX-Updates ab oder starten danach nicht mehr. Pilotieren Sie jedes Modell.
Dual-Boot- und Linux-Systeme hängen von der Drittanbieter-UEFI-CA ab; deren Deaktivierung oder das Sperren von Shims betrifft sie.
BitLocker-Wiederherstellungsaufforderungen auf Geräten ohne PCR-7-Bindung. Bestätigen Sie zuerst die Hinterlegung mit dem Leitfaden zu Wiederherstellungsschlüsseln und halten Sie BitLocker rund um Firmwareupdates für einen Neustart an (Suspend-BitLocker -MountPoint C: -RebootCount 1).
Option-ROMs von Zusatzgrafikkarten und Speichercontrollern benötigen womöglich die Drittanbieter-CA.

Überprüfen

Confirm-SecureBootUEFI liefert auf jedem Gerät True.
Die DB enthält Windows UEFI CA 2023, der KEK enthält Microsoft Corporation KEK 2K CA 2023 (Befehle in Schritt 1).
Das Systemprotokoll zeigt die Bestätigungsereignisse für jeden angewendeten Schritt (1808, sobald alle Zertifikate vorhanden sind), UEFICA2023Status hat den Wert Updated, und AvailableUpdates enthält die gesetzten Bits nicht mehr (ein verbleibendes 0x4000 nach 0x5944 ist erwartet).
Auf Geräten mit Sperrung startet ein altes, mit PCA 2011 signiertes Startmedium nicht und meldet eine Secure-Boot-Verletzung. Testen Sie das einmal pro Modell im Labor, nicht in der Produktion.
Die Intune-Compliance meldet Secure Boot als intakt; Measured-Boot-Protokolle unter C:\Windows\Logs\MeasuredBoot sind für die Attestierung vorhanden.

Checkliste

Alle Geräte starten im UEFI-Modus mit aktiviertem Secure Boot im Standardmodus
Inventar des Zustands von DB, KEK und Start-Manager pro Gerät und pro Modell
Windows UEFI CA 2023 in der DB und mit 2023 signierter Start-Manager überall installiert
KEK von 2023 bereitgestellt; Modelle mit nötigem Firmwareupdate identifiziert und aktualisiert
Startmedien, PXE-Abbilder, WinRE und VM-Vorlagen aktualisiert
Sperrung von PCA 2011 und SVN-Update nach der Medienaktualisierung Ring für Ring angewendet
Firmwarekennwort gesetzt, Legacy-Start und externer Start deaktiviert, Einstellungen gesperrt

Eine vertrauenswürdige Startkette ist die Grundlage für Credential Guard und die Speicherintegrität. Im Glossareintrag zu Secure Boot finden Sie eine kürzere Definition, die Sie mit Nicht-Spezialisten teilen können.