BlackX: Neues UEFI-Bootkit umgeht Secure Boot auf Windows-Systemen
Ein aktueller Bericht von Kaspersky zeigt ziemlich eindrucksvoll, warum „Windows ist vollständig gepatcht“ nicht automatisch bedeutet, dass auch jede Sicherheitsmaßnahme tatsächlich aktiv ist.
Sicherheitsforscher haben mit BlackX ein neues UEFI-Bootkit untersucht, das bei Angriffen auf diplomatische Einrichtungen in Zentralasien eingesetzt wurde.
Betroffen waren Organisationen in:
Tadschikistan
Usbekistan
Turkmenistan
Besonders brisant: Die angegriffenen Windows-Systeme waren laut Kaspersky vollständig aktualisiert.
Trotzdem konnte BlackX Secure Boot umgehen.
Der Grund liegt in einer Schutzmaßnahme, die bei vielen Systemen offenbar nie vollständig aktiviert wurde.
Was ist BlackX überhaupt?
BlackX ist ein sogenanntes UEFI-Bootkit.
Normale Schadsoftware startet üblicherweise erst zusammen mit Windows oder innerhalb des laufenden Betriebssystems.
Ein Bootkit setzt deutlich früher an.
Es manipuliert Teile des Startvorgangs, bevor Windows vollständig geladen wurde.
Dadurch kann Schadcode bereits aktiv sein, während das Betriebssystem und dessen Sicherheitsprogramme erst hochfahren.
Für Angreifer ist das ausgesprochen attraktiv.
Wenn die eigene Malware schon vor Windows sitzt, hat sie eine hervorragende Ausgangsposition, um sich zu verstecken und Sicherheitslösungen zu beeinflussen.
BlackX ist kein Erstzugang zum Rechner
An dieser Stelle ist eine wichtige Einordnung nötig.
BlackX ist kein Angriff, mit dem ein beliebiger Rechner aus dem Internet heraus übernommen wird.
Kaspersky beobachtete das Bootkit erst, nachdem die Angreifer bereits in die jeweiligen Netzwerke eingedrungen waren und Administratorrechte erlangt hatten.
Wie dieser ursprüngliche Zugriff erfolgte, ist bislang nicht bekannt.
Erst danach wurde BlackX installiert.
Das Bootkit dient also vor allem der:
dauerhaften Verankerung
Umgehung von Sicherheitsmechanismen
Tarnung
Spionage
Wer keine administrativen Rechte oder physischen Zugriff auf einen Rechner besitzt, kann BlackX nicht einfach mal eben installieren.
Die Verbindung zu BlackLotus
Technisch erinnert BlackX stark an BlackLotus.
BlackLotus sorgte bereits 2022 und 2023 für Schlagzeilen.
Das Bootkit konnte Secure Boot umgehen und war zeitweise für rund 5.000 US-Dollar in einschlägigen Cybercrime-Foren erhältlich.
BlackX scheint viele Ideen beziehungsweise Techniken davon übernommen zu haben.
Interessant ist dabei:
Der Quellcode von BlackLotus wurde nie öffentlich veröffentlicht.
Die Entwickler von BlackX könnten das ursprüngliche Bootkit daher entweder aufwendig analysiert und nachgebaut oder auf anderem Weg Zugriff auf dessen Code bekommen haben.
Kaspersky spricht jedenfalls von auffallend großen Ähnlichkeiten.
Alte Schwachstelle, neuer Angriff
Im Mittelpunkt steht die Sicherheitslücke:
CVE-2022-21894
Sie wird auch als Baton Drop bezeichnet.
Die Schwachstelle ermöglicht es, Schutzmechanismen rund um Secure Boot zu umgehen und nicht autorisierten Code bereits während des Startvorgangs auszuführen.
Microsoft hat das Problem bereits vor Jahren adressiert.
Eigentlich müsste man also denken:
Problem bekannt, Patch installiert, Geschichte erledigt.
Ganz so einfach ist es leider nicht.
Vollständig gepatcht – und trotzdem verwundbar
Genau das ist der interessante Teil des BlackX-Falls.
Kaspersky stellte zunächst ebenfalls die naheliegende Vermutung auf, dass die betroffenen Systeme schlicht nicht aktualisiert worden waren.
Die Analyse zeigte jedoch:
Die Rechner waren gepatcht.
Das eigentliche Problem lag bei der Secure-Boot-Sperrliste.
Microsofts Schutzmaßnahmen gegen entsprechende Bootkits bestehen nicht nur aus einem normalen Windows-Update.
Bestimmte alte Boot-Komponenten müssen zusätzlich über die UEFI-Sperrliste DBX als nicht mehr vertrauenswürdig markiert werden.
Und genau dieser Schritt war auf den betroffenen Systemen offenbar nicht vollständig umgesetzt worden.
Was ist die DBX?
Secure Boot arbeitet vereinfacht mit mehreren Listen.
Eine davon enthält Zertifikate und Signaturen, denen das System vertraut.
Eine andere enthält Dinge, die ausdrücklich nicht mehr gestartet werden dürfen.
Diese Sperrliste wird als:
DBX – Forbidden Signature Database
bezeichnet.
Im aktuellen Fall ist insbesondere das Zertifikat:
Microsoft Windows Production PCA 2011
relevant.
Ältere Windows-Bootmanager wurden damit signiert.
Genau darunter befinden sich auch verwundbare Komponenten, die von Angriffen wie BlackLotus beziehungsweise BlackX missbraucht werden können.
Ein installiertes Update reicht nicht automatisch
Microsoft hat für diesen Übergang umfangreiche Secure-Boot-Maßnahmen bereitgestellt.
Das Problem:
Die vollständige Revocation alter Bootmanager wurde lange bewusst nicht einfach ungefragt auf allen Systemen aktiviert.
Der Grund ist nachvollziehbar.
Wer alte Rettungsmedien, spezielle Bootloader, bestimmte Dual-Boot-Konfigurationen oder ältere Unternehmenslösungen verwendet, könnte nach einer solchen Sperre plötzlich nicht mehr davon starten.
Deshalb musste die Umstellung sorgfältig vorbereitet werden.
Das ist technisch vernünftig.
In der Praxis entsteht dadurch allerdings eine gefährliche Situation:
Ein Administrator sieht ein vollständig aktualisiertes Windows und geht davon aus, dass die bekannte Schwachstelle erledigt ist.
Die entscheidende Secure-Boot-Revocation fehlt aber möglicherweise trotzdem.
Genau darauf setzt BlackX
Kaspersky vermutet, dass die Angreifer diesen Umstand bewusst ausnutzen.
Viele Unternehmen dürften die normalen Windows-Updates installiert haben, ohne die zusätzlichen Secure-Boot-Maßnahmen vollständig umzusetzen.
Damit bleibt ein interessantes Angriffsfenster offen.
Der Angreifer benötigt zwar bereits administrative Kontrolle.
Hat er diese aber einmal erreicht, kann BlackX ältere verwundbare Boot-Komponenten verwenden, die das System weiterhin akzeptiert.
Das finde ich an der Geschichte fast bedenklicher als irgendeinen neuen Zero-Day.
Die Sicherheitslücke ist alt.
Der Schutz existiert.
Aber er ist nicht zwangsläufig vollständig aktiv.
Das alte Zertifikat ist inzwischen abgelaufen
Zusätzlich kommt ein zeitlicher Faktor hinzu.
Das Zertifikat Microsoft Windows Production PCA 2011 ist am 19. Oktober 2026 abgelaufen.
Das allein löst das Problem allerdings nicht.
Ein abgelaufenes Zertifikat bedeutet bei Secure Boot nicht automatisch, dass bereits damit signierte Binärdateien plötzlich blockiert werden.
Dafür müssen die entsprechenden Signaturen beziehungsweise das Zertifikat tatsächlich in der Sperrliste landen.
Mit anderen Worten:
Abgelaufen ist nicht dasselbe wie gesperrt.
Genau diese Feinheit nutzt BlackX aus.
Microsoft stellt inzwischen auf neue Zertifikate um
Microsoft befindet sich seit längerer Zeit mitten in einer größeren Secure-Boot-Umstellung.
Die alten Zertifikate aus dem Jahr 2011 werden durch neue Zertifikate aus dem Jahr 2023 ersetzt.
Dazu gehören unter anderem:
Windows UEFI CA 2023
und neue Schlüssel für weitere UEFI-Komponenten.
Die Umstellung besteht allerdings aus mehreren Schritten.
Zunächst muss das System den neuen Zertifikaten vertrauen.
Danach müssen aktualisierte Bootmanager verwendet werden.
Erst anschließend können die alten Zertifikate sicher gesperrt werden.
Würde man die Reihenfolge umdrehen, könnte man im schlimmsten Fall einen Rechner produzieren, der nicht mehr startet.
Also nicht einfach blind irgendwelche Secure-Boot-Werte ändern
Deshalb würde ich an dieser Stelle ausdrücklich nicht empfehlen, jetzt einfach irgendwelche Registry-Werte aus dem Internet zu kopieren.
Die Microsoft-Maßnahmen verändern die Secure-Boot-Vertrauenskette.
Das kann Auswirkungen auf:
ältere Windows-Installationsmedien
Wiederherstellungsmedien
Dual-Boot-Systeme
spezielle UEFI-Anwendungen
ältere Hardware
haben.
Gerade in Unternehmen sollten die Änderungen zunächst auf repräsentativer Hardware getestet werden.
Das ist einer dieser Fälle, bei denen „einfach schnell absichern“ durchaus dazu führen kann, dass man anschließend sehr sicher nicht mehr bootet.
BlackX manipuliert den Windows-Startvorgang
Nach der Installation schreibt BlackX Komponenten sowohl auf die Systempartition als auch auf die UEFI-Partition.
Ziel ist es, eigene Machine Owner Keys einzurichten beziehungsweise den Secure-Boot-Prozess so zu beeinflussen, dass anschließend beliebige EFI-Komponenten geladen werden können.
Beim Start wird dann ein bösartiger Treiber in den Windows-Kernel eingeschleust.
Damit sitzt die Malware an einer ausgesprochen privilegierten Stelle.
Und von dort aus versucht sie, weitere Sicherheitsmechanismen zu beeinflussen.
Sicherheitsprogramme sollen ausgeschaltet werden
Der von BlackX geladene Kernel-Treiber versucht unter anderem, Funktionen von Endpoint-Security-Software zu manipulieren.
Dazu gehören Mechanismen für:
Prozesse
Threads
Registry-Zugriffe
Windows Event Tracing
Einige Routinen reagieren laut Kaspersky gezielt darauf, ob Produkte von Kaspersky oder Avast installiert sind.
Interessanterweise funktionierten zumindest bestimmte gegen Kaspersky gerichtete Manipulationen in den Tests der Forscher nicht wie vorgesehen.
Der Wille war also offenbar vorhanden.
Die technische Umsetzung nicht überall.
Der Treiber war sogar digital signiert
BlackX verwendet außerdem einen signierten Kernel-Treiber.
Das verwendete Zertifikat gehörte laut Analyse zu einem Unternehmen namens:
Wenjiang District Mingyu Network Technology Service Studio
Das Zertifikat wurde inzwischen vom Herausgeber widerrufen.
Auch das zeigt ein altbekanntes Problem moderner Angriffe:
Eine gültige digitale Signatur bedeutet nicht automatisch, dass Software harmlos ist.
Sie beantwortet zunächst nur die Frage, mit welchem Zertifikat eine Datei signiert wurde.
Danach beginnt die eigentliche Spionage
BlackX beschränkt sich nicht darauf, möglichst tief im Rechner zu sitzen.
Über weitere Payloads werden klassische Spionagefunktionen nachgeladen.
Kaspersky beobachtete unter anderem einen Remote-Access-Trojaner.
Dieser kann:
Systeminformationen sammeln
Dateien hochladen
Dateien herunterladen
weitere .NET-Payloads ausführen
Besonders interessant ist die Kommunikation mit den Angreifern.
Google Drive, OneDrive und Yandex.Disk als Tarnung
Der Trojaner verwendet teilweise normale Cloud-Dienste für seine Command-and-Control-Kommunikation.
Beobachtet wurden:
Google Drive
Microsoft OneDrive
Yandex.Disk
Das ist ziemlich geschickt.
Eine Verbindung zu einer offensichtlich dubiosen Serveradresse fällt in einem Unternehmensnetzwerk schnell auf.
Eine Verbindung zu OneDrive?
Davon gibt es je nach Unternehmen möglicherweise tausende am Tag.
Genau dadurch lässt sich Schadverkehr besser zwischen legitimen Unternehmensaktivitäten verstecken.
Eine zweite Malware nutzt DLL-Sideloading
Kaspersky beobachtete außerdem eine weitere Komponente namens OxiDLLRunner.
Hier wird ein legitimes Programm dazu missbraucht, eine schädliche DLL zu laden.
Das Verfahren nennt sich DLL-Sideloading.
Die anschließend entschlüsselte Payload wurde in Rust entwickelt und kann weitere Plugins vom Command-and-Control-Server empfangen und ausführen.
Das zeigt, dass BlackX nicht nur ein einzelnes Bootkit ist.
Dahinter steckt eine komplette Angriffskette für langfristige Spionage.
Verbindung zu APT41
Kaspersky ordnet die Kampagne mit mittlerer Sicherheit APT41 zu.
APT41 wird üblicherweise mit China in Verbindung gebracht.
Die Zuordnung basiert allerdings nicht auf einem einzelnen eindeutigen Beweis.
Stattdessen nennt Kaspersky mehrere technische Überschneidungen.
Dazu gehören unter anderem:
wiederkehrende interne Bezeichner
Ähnlichkeiten zu früheren FishMonger-Angriffen
DLL-Sideloading
bestimmte Verschleierungstechniken
Deshalb sollte man hier sauber formulieren:
Kaspersky vermutet APT41 hinter BlackX. Eine zweifelsfreie Attribution ist das nicht.
Gerade bei staatlich orientierten Angriffen ist diese Unterscheidung wichtig.
Für normale Privatanwender eher kein akutes Massenthema
So technisch beeindruckend BlackX ist:
Für einen gewöhnlichen Windows-Heimrechner würde ich daraus momentan keine unmittelbare Panik ableiten.
Die beobachteten Angriffe richteneten sich gezielt gegen diplomatische Einrichtungen.
Außerdem mussten die Täter vorher bereits Administratorrechte auf dem Zielsystem besitzen.
Das ist also kein Szenario, bei dem jemand einfach eine Webseite besucht und anschließend steckt plötzlich ein UEFI-Bootkit im Rechner.
Für Unternehmen, Behörden und besonders sensible Umgebungen sieht das anders aus.
Dort ist Secure-Boot-Härtung ein wichtiges Thema.
Unternehmen sollten den tatsächlichen Secure-Boot-Status prüfen
Gerade Administratoren sollten deshalb nicht nur kontrollieren:
Sind alle Windows-Updates installiert?
Sondern auch:
Sind die vorgesehenen Secure-Boot-Mitigationen tatsächlich umgesetzt?
Microsoft dokumentiert inzwischen ausführlich, wie die Migration von den Zertifikaten aus dem Jahr 2011 auf die Generation 2023 durchgeführt und überprüft werden kann.
Dabei sollten auch vorhandene Boot- und Wiederherstellungsmedien berücksichtigt werden.
Das ist Arbeit.
Aber BlackX zeigt ziemlich gut, warum diese Arbeit notwendig ist.
Mein Eindruck
Ich finde an BlackX besonders interessant, dass die eigentliche Schwachstelle gar nicht neu ist.
CVE-2022-21894 stammt aus einer inzwischen ziemlich alten Sicherheitsgeschichte.
Und trotzdem funktioniert das Konzept 2026 noch gegen vollständig gepatchte Systeme.
Nicht, weil Microsoft überhaupt keinen Fix geliefert hätte.
Sondern weil die vollständige Absicherung komplizierter ist als ein normaler Windows-Patch.
Das ist aus Administratorensicht unangenehm.
Wir sind darauf trainiert:
Updates installieren, Neustart, erledigt.
Bei Secure Boot funktioniert das teilweise anders.
Und genau diese Lücke zwischen „Patch vorhanden“ und „Schutz tatsächlich aktiviert“ scheint BlackX sehr gezielt auszunutzen.
Fazit
Mit BlackX hat Kaspersky ein neues UEFI-Bootkit entdeckt, das bei gezielten Angriffen auf diplomatische Einrichtungen in Zentralasien eingesetzt wurde.
Die Malware ähnelt stark dem bekannten BlackLotus-Bootkit und nutzt die ältere Secure-Boot-Schwachstelle CVE-2022-21894.
Besonders bemerkenswert:
Die betroffenen Windows-Rechner waren vollständig gepatcht.
Entscheidend war offenbar, dass die notwendigen Secure-Boot-Revocations nicht vollständig aktiviert worden waren.
Dadurch konnten weiterhin ältere verwundbare Boot-Komponenten gestartet werden.
BlackX nutzt diese Situation, um sich bereits vor Windows in den Startvorgang einzuklinken, einen Kernel-Treiber nachzuladen und anschließend Spionagekomponenten auszuführen.
Kaspersky ordnet die Kampagne mit mittlerer Sicherheit dem mit China in Verbindung gebrachten APT41-Umfeld zu.
Für Privatanwender ist das momentan kein Grund zur Panik.
Für Unternehmen und Behörden ist die Botschaft dagegen ziemlich eindeutig:
Ein vollständig gepatchtes Windows ist nur die halbe Wahrheit, wenn die dazugehörigen Secure-Boot-Schutzmaßnahmen nicht ebenfalls vollständig umgesetzt wurden.
Quellen
The Hacker News:
BlackX UEFI Bootkit Bypasses Secure Boot on Patched Windows Systems Missing Revocations
https://thehackernews.com/2026/10/blackx-uefi-bootkit-bypasses-secure.html
Kaspersky Securelist – technische BlackX-Analyse:
https://securelist.com/uefi-bootkit-blackx/121539/
Microsoft – Enterprise Deployment Guidance für CVE-2023-24932:
https://support.microsoft.com/en-us/servicing/os/windows/2025/02/enterprise-deployment-guidance-for-cve-2023-24932
Microsoft – Verwaltung der Windows-Bootmanager-Revocations:
https://support.microsoft.com/en-us/servicing/os/windows/2023/03/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932