Warum BlackLotus die Spielregeln verändert hat
Als der ESET-Forscher Martin Smolár am 1. März 2023 auf WeLiveSecurity die Analyse eines neuen UEFI-Bootkits veröffentlichte, beendete er eine jahrelange Diskussion: BlackLotus war das erste öffentlich dokumentierte Bootkit, das auf einem vollständig gepatchten Windows 11 mit aktivem Secure Boot persistent Code unterhalb des Betriebssystems ausführen konnte. Was zuvor als theoretisches APT-Werkzeug galt, wurde damit zur kommerziellen Realität — angeboten in russischsprachigen Untergrundforen seit Oktober 2022 für rund 5.000 USD plus Aufpreis pro neuer Version.
Drei Jahre später ist BlackLotus selbst nur noch eine Fußnote in der Liste der UEFI-Implants. Die strukturellen Probleme, die seine Existenz erst ermöglicht haben, sind jedoch nicht verschwunden: Signierte, aber verwundbare Bootloader-Binaries lassen sich praktisch nicht widerrufen, die DBX-Sperrliste ist auf vielen Mainboards zu klein, und die Vertrauenskette zwischen Firmware, Bootloader und Betriebssystem ist nur so robust wie ihr schwächstes Glied.
Dieser Artikel sortiert die technische Mechanik von BlackLotus ein, ordnet die vier Phasen der Microsoft-Revokation (CVE-2023-24932) ein und beschreibt, wie wir in Assessments eine Infektion erkennen — auch nach Jahren der stillen Persistenz. Wer den parallelen Zertifikatswechsel auf die Windows UEFI CA 2023 noch vor sich hat, findet die Migrationsschritte in unserem Leitfaden zur UEFI-CA-2023-Migration.
Die Anatomie eines Secure-Boot-Bypasses
Im Kern nutzt BlackLotus einen Logikfehler im Boot Manager bootmgfw.efi, der unter der CVE-Kennung CVE-2022-21894 geführt wird und intern als „Baton Drop" bekannt ist. Microsoft hat die Schwachstelle bereits im Januar-2022-Patchday geschlossen — nur eben im aktuellen Bootloader. Die zuvor signierten, anfälligen Vorgängerversionen blieben weiterhin in jeder Microsoft-signierten Vertrauenskette gültig. Genau hier setzt BlackLotus an.
Das Vorgehen ist ein Lehrbuchfall für Bring Your Own Vulnerable Binary (BYOVB): Der Installer kopiert eine alte, legitim signierte Version des Boot Managers auf die EFI System Partition, manipuliert die Boot Configuration Data, sodass dieser angreifbare Bootloader anstelle des aktuellen geladen wird, und löst über den Baton-Drop-Fehler eine Manipulation der Secure-Boot-Policy aus. Anschließend wird ein eigener Machine Owner Key in die NVRAM-Variable MokList geschrieben, der als zusätzlicher Vertrauensanker für das selbstsignierte Bootkit fungiert.
Sobald der eigene Bootkit-Stack geladen ist, läuft die Kette weiter: Ein UEFI-Treiber, ein Boot-Anwender und schließlich ein Kernel-Treiber, der nach dem Windows-Start die folgenden Schutzmechanismen gezielt deaktiviert oder umgeht:
- BitLocker-Integritätsprüfungen über den TPM-PCR-Vergleich
- HVCI (Hypervisor-Enforced Code Integrity)
- Microsoft Defender und Windows Driver Signature Enforcement
- Optional Credential Guard je nach Variante
Erst danach wird der HTTP-basierte Loader für die eigentliche Payload aktiv. Die Geofencing-Logik des Bootkits verschont dabei Systeme mit Locale-Einstellungen aus Armenien, Belarus, Kasachstan, Moldau, Rumänien, Russland und der Ukraine — ein Indiz für die Herkunft des Akteurs, das Smolár in der Erstanalyse explizit hervorgehoben hat.
Warum klassische Härtung hier nicht greift
Die unangenehme Wahrheit an BlackLotus ist, dass viele etablierte Härtungsmaßnahmen den Angriff nicht verhindern. Secure Boot war aktiv. Die Windows-Updates waren eingespielt. Defender war aktiviert. BitLocker schützte das Volume. Trotzdem konnte das Bootkit persistent werden, weil der Vertrauensanker — die signierten Boot-Manager-Binaries von Microsoft — selbst zur Waffe wurde.
Diese Klasse von Angriffen lässt sich nicht durch klassisches Patch-Management adressieren. Ein verwundbarer signierter Bootloader bleibt für die Firmware vertrauenswürdig, bis sein Hash explizit auf die Sperrliste DBX gesetzt wird. Genau das ist der Kern des Problems: Die DBX hat auf vielen Geräten nur wenige Kilobyte Speicher und kann nicht beliebig viele Hashes aufnehmen.
CVE-2023-24932: Microsoft braucht vier Phasen
Microsoft hat den Fix für die BlackLotus-Voraussetzungen unter CVE-2023-24932 (KB5025885) ausgerollt — und dabei einen ungewöhnlich vorsichtigen, mehrphasigen Ansatz gewählt. Der Grund: Eine fehlerhafte DBX-Aktualisierung kann in letzter Konsequenz dazu führen, dass Geräte gar nicht mehr booten — DBX-Einträge sind nicht-flüchtig und nicht ohne weiteres rückrollbar.
| Phase | Termin | Inhalt |
|---|---|---|
| Initial Deployment | 9. Mai 2023 | Patch + manuelle Revocation-Files (opt-in) |
| Second Deployment | 11. Juli 2023 | Automatisierte Revocation-Logik, neue Event-IDs, SafeOS Dynamic Update für WinRE |
| Third Deployment | 9. April 2024 | Erweiterte Boot-Manager-Mitigations, SVN-Erhöhung |
| Mandatory Enforcement | verschoben in 2026 | Erzwungene Revocation auf allen Systemen |
Bemerkenswert ist die letzte Phase: Microsoft hatte die Mandatory Enforcement ursprünglich für Anfang 2024 angekündigt, dann auf „frühestens Januar 2026" verschoben und zuletzt mit dem Migrationsfenster der Windows UEFI CA 2023 verzahnt. Stand Mai 2026 ist die Erzwingung noch nicht aktiv — was bedeutet, dass Bestandsgeräte mit den alten, verwundbaren Boot-Manager-Versionen weiterhin starten können, sofern der Administrator die Revocation nicht aktiv ausgelöst hat.
Die SVN-Lösung für das DBX-Speicherproblem
Hunderte einzelne Hashes aller verwundbaren Boot-Manager-Versionen in die DBX zu schreiben, scheitert an den Speichergrenzen vieler Mainboards. Microsoft hat deshalb das Konzept der Secure Version Number (SVN) eingeführt. Statt jeden anfälligen Hash einzeln zu sperren, schreibt eine Policy-Datei (SkuSiPolicy.p7b) eine Mindestversionsnummer in die DBX. Boot Manager mit niedrigerer SVN starten nicht — unabhängig von ihrer individuellen Signatur. Mit den April-2024-Updates wurde die SVN auf 7.0 angehoben, was alle BlackLotus-relevanten Bootloader-Versionen mit einem einzigen Eintrag aussperrt.
Die Endphase sieht zudem vor, das Windows Production PCA 2011 selbst in die DBX einzutragen — der Vertrauensanker, mit dem BlackLotus seine signierten Hilfsmittel überhaupt erst missbrauchen konnte. Das passt strukturell zur parallelen Migration auf die Windows UEFI CA 2023 und erklärt, warum Microsoft beide Prozesse zeitlich verzahnt.
Detection: Wo wir Spuren in der Praxis finden
In Assessments suchen wir nach BlackLotus-Indikatoren auf vier Ebenen. Keine einzelne Quelle ist beweisend, aber die Kombination aus mehreren passenden Signalen rechtfertigt eine forensische Tiefenuntersuchung.
EFI System Partition. Eine direkte Spur ist das Verzeichnis ESP:\system32\, das Bootkit-Komponenten enthält und nach der Installation nicht mehr automatisch entfernt wird. Auch ungewöhnliche .efi-Dateien — etwa eine bootmgfw.efi mit ungewöhnlicher Größe oder ein grubx64.efi auf einem reinen Windows-System — sind verdächtig. In einigen Fällen sind Bootkit-Dateien gegen Lesezugriffe gesperrt, was sich durch Vergleich mit bekannten Hashes nicht prüfen lässt; hier hilft ein Offline-Mount der ESP über ein Recovery-Medium.
NVRAM-Variablen. Die MokList-Variable wird normalerweise nur durch eine signierte Linux-Distribution gesetzt. Auf einem reinen Windows-Gerät ist ein zusätzlicher MOK-Eintrag ein starkes Verdachtsmoment. Der Abgleich erfolgt über mokutil (Linux-Live-System) oder über UEFI-Tools, die NVRAM-Variablen exportieren.
Windows-Registry und Event Log. Wenn das Bootkit aktiv ist, deaktiviert es HVCI über den Schlüssel HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity (Enabled=0). Ein Vergleich gegen die per GPO oder Intune gesetzte Soll-Konfiguration deckt die Manipulation auf. Mit dem Juli-2023-Update hat Microsoft zusätzlich neue Event-IDs eingeführt, die den Revocation-Status protokollieren.
Measured Boot und TPM-Attestation. Die robusteste Erkennungsschicht ist der Vergleich der TPM-PCR-Werte (insbesondere PCR[0,2,4,7]) über mehrere Reboots oder gegen einen bekannten Goldstand. Eine Attestierung über Microsoft Azure Attestation, Intune Compliance oder Spezialprodukte wie Eclypsium liefert hierfür belastbare Daten. Dies ist auch die einzige Erkennungsschicht, die eine theoretische BlackLotus-Variante mit besserer Tarnung noch erfasst.
Die Krux mit Linux-Dual-Boot
DBX-Updates haben eine Eigenart, die in heterogenen Umgebungen regelmäßig zu Boot-Ausfällen führt: Sie sind nicht-flüchtig (NV) und können nicht „rückgängig" gemacht werden. Werden sie eingespielt, ohne dass die Linux-Komponenten — insbesondere shim und GRUB2 — auf signierte, unter den neuen Regeln gültige Versionen aktualisiert sind, startet die Linux-Partition nicht mehr.
Red Hat, Ubuntu, Debian und SUSE haben parallel zu KB5025885 SBAT-Updates ausgerollt, die genau dieses Problem adressieren. Vor dem Anwenden eines DBX-Updates auf einem Dual-Boot-System gilt deshalb die Reihenfolge: zuerst alle installierten Linux-Distributionen vollständig aktualisieren, dann den DBX-Stand des Systems über mokutil --list-sbat-revocations prüfen, erst danach den Microsoft-Patch anwenden. Red Hat selbst stellt klar, dass RHEL nicht durch BlackLotus angreifbar ist — der Kollateralschaden durch Microsoft-DBX-Updates trifft Linux-Systeme aber trotzdem.
Der Kontext: BlackLotus ist nicht allein
UEFI-Implants haben eine längere Geschichte als die öffentliche Diskussion vermuten lässt. Die folgende Übersicht ordnet BlackLotus in die Reihe der bekannten Familien ein:
| Implant | Jahr | Zuordnung | Besonderheit |
|---|---|---|---|
| LoJax | 2018 | Sednit / APT28 | Erstes ITW-UEFI-Rootkit, SPI-Flash |
| MosaicRegressor | 2020 | unbekannte APT | Modulares UEFI-Implant |
| ESPecter | 2021 | unbekannt | ESP-basiert, ohne Secure-Boot-Bypass |
| MoonBounce | 2022 | APT41 | SPI-Flash-Implant in CORE_DXE |
| CosmicStrand | 2022 | unbekannt | UEFI-Implant in modifizierten ASUS/Gigabyte-Firmware-Images |
| BlackLotus | 2023 | kommerziell | Erster Secure-Boot-Bypass auf Windows 11 |
| BootHole (CVE-2020-10713) | 2020 | n/a (Schwachstelle) | GRUB2-Buffer-Overflow, betraf alle Linux-Distros mit shim |
Was BlackLotus von den meisten APT-Implants unterscheidet, ist die kommerzielle Verfügbarkeit. UEFI-Bootkits waren lange das Werkzeug staatlicher Akteure mit physischem oder tiefem Lieferketten-Zugriff. BlackLotus hat diese Schwelle gesenkt — und damit den Druck auf alle anderen Hersteller, ihre Vertrauensketten zu härten, deutlich erhöht.
Praxisempfehlung: Was wir aktuell empfehlen
In unserer Systemhärtungs-Praxis sehen wir, dass viele Organisationen die KB5025885-Phasen nicht vollständig durchgezogen haben. Der typische Stand: Patch installiert, aber Revocation nicht angewendet. Das schließt die Schwachstelle nicht — der verwundbare Bootloader bleibt vertrauenswürdig.
Schritt 1: KB5025885 vollständig anwenden. Das bedeutet nicht nur den Patch, sondern auch das Setzen des Registry-Werts, der die Revocation-Anwendung auslöst. Microsoft beschreibt die genaue Sequenz im Enterprise-Deployment-Guide. Wir empfehlen die Anwendung in einem Pilotring und die Verifikation per Event-Log und Registry-Status, bevor der breite Rollout startet.
Schritt 2: HVCI und VBS erzwingen. Auch ein wirksames Bootkit muss letztlich Code im Kernel ausführen, um nutzbar zu sein. Virtualization-Based Security und HVCI heben die Hürde dafür deutlich an. In Kombination mit Credential Guard und einem TPM 2.0 entsteht eine Vertrauenskette, die Bootkits dieser Generation kaum noch nutzbar lässt.
Schritt 3: Measured Boot mit Attestation. Wer die Firmware-Sicherheit ernst nimmt, kommt um Remote Attestation nicht herum. Intune Compliance Policies können TPM-PCR-Werte als Bedingung für Conditional Access verwenden — Geräte mit unerwarteter Boot-Chain werden so von Unternehmensressourcen abgeschnitten, bevor ein Bootkit Schaden anrichten kann.
Schritt 4: UEFI-CA-2023-Migration mitnehmen. BlackLotus-Mitigation und Zertifikatsmigration laufen technisch über dieselben Werkzeuge. Wer die Revocation phasengerecht ausrollt, schafft sich gleichzeitig die Voraussetzung für die UEFI-CA-2023-Migration, die bis zum Ablauf der Microsoft Production PCA 2011 im Oktober 2026 abgeschlossen sein muss.
Schritt 5: Re-Image bei begründetem Verdacht. Bei einer bestätigten BlackLotus-Infektion ist die NSA-Empfehlung aus dem BlackLotus Mitigation Guide vom 22. Juni 2023 eindeutig: ESP wipen, Disk neu partitionieren, frisches Image aufspielen. Manuelles Cleanup ist riskant, weil das Bootkit Dateien sperren und einzelne Komponenten verstecken kann. Die NSA hat im Dezember 2025 einen aktualisierten Leitfaden „Guidance for Managing UEFI Secure Boot" veröffentlicht, der diese Empfehlung bestätigt.
Was bleibt von BlackLotus?
BlackLotus ist heute weniger relevant als seine strukturellen Voraussetzungen. Der Verkauf in Hackerforen ist abgeebbt, EDR-Produkte erkennen die bekannten Varianten, und die Revocation-Hashes werden mit jedem Patchday breiter ausgerollt. Die zugrundeliegenden Probleme — signierte verwundbare Bootloader, knappe DBX-Speicher, fehlende Attestierung in Bestandsumgebungen — sind aber nicht verschwunden.
Das nächste BlackLotus wartet vermutlich schon. Die Frage ist nicht, ob ein anderer signierter Bootloader-Bug ausnutzbar wird, sondern wie schnell die Vertrauenskette dann reagieren kann. Wer Measured Boot, TPM-Attestation und Defense in Depth heute nicht ausgerollt hat, wird bei der nächsten Welle dieselben Probleme haben — nur mit einem anderen Namen.
Firmware-Sicherheit ganzheitlich bewerten lassen. In unserem Systemhärtungs-Assessment prüfen wir Secure-Boot-Status, KB5025885-Revocation-Stand, HVCI/VBS-Konfiguration und die TPM-Attestierungsfähigkeit Ihrer Geräteflotte — und liefern einen konkreten Maßnahmenplan inklusive Erkennungssignaturen für vorhandene EDR-Lösungen. Systemhärtungs-Assessment anfragen.