BlackX-UEFI-Bootkit nutzt alte Schwachstelle aus, um Secure Boot zu umgehen

Das BlackX-UEFI-Bootkit umging Secure Boot während einer Spionagekampagne gegen diplomatische Behörden in Zentralasien. Forscher entdeckten die Operation Anfang 2026, wobei sich die Ziele hauptsächlich in Tadschikistan, Usbekistan und Turkmenistan befanden.

Kaspersky brachte die Kampagne mit mittlerer Sicherheit mit der chinesischen staatlich unterstützten Gruppe APT41 in Verbindung. Diese Einschätzung stellt die Zuordnung jedoch nicht zweifelsfrei fest.

Die Schadsoftware nutzte Baton Drop aus, eine ältere Schwachstelle mit der Kennung CVE-2022-21894. Anschließend lud sie einen schädlichen Windows-Treiber und weitere Spionagewerkzeuge.

BlackX-UEFI-Bootkit weist Ähnlichkeiten mit BlackLotus auf

Forscher entdeckten deutliche Ähnlichkeiten zwischen BlackX und BlackLotus, einem weiteren Bootkit, das Baton Drop ausnutzte, um Secure Boot zu umgehen.

Secure Boot überprüft normalerweise Startkomponenten, bevor das System deren Ausführung zulässt. Anfällige Komponenten können diesen Schutz jedoch untergraben, wenn Systeme ihnen weiterhin vertrauen.

Laut Kaspersky verwenden beide Bootkits eng verwandte Methoden, um angreiferkontrollierte Machine Owner Keys zu registrieren. Dadurch können schädliche EFI-Komponenten trotz des Secure-Boot-Schutzes geladen werden.

Allerdings verwendet BlackX einen anderen Kernel-Treiber und andere nachgelagerte Nutzlasten.

Die Forscher vermuten, dass die Entwickler entweder BlackLotus zurückentwickelt oder über das öffentliche Leak hinaus Zugang zu dessen Quellcode erhalten haben.

Obwohl im Juli 2023 jemand den BlackLotus-Quellcode veröffentlichte, war diese Veröffentlichung unvollständig. BlackX enthält Code, den die Forscher in BlackLotus-Samples fanden, jedoch nicht im öffentlichen Repository.

Schädlicher Treiber greift Sicherheitsüberwachung an

BlackX lädt einen Windows-Kernel-Treiber, der mit einem Zertifikat signiert wurde, das die zuständigen Stellen inzwischen widerrufen haben.

Das Zertifikat gehörte einer Organisation namens Wenjiang District Mingyu Network Technology Service Studio.

Nach seiner Aktivierung versucht der Treiber, Sicherheitsprozesse und Registry-Callbacks zu deaktivieren. Außerdem beeinträchtigt er Event Tracing for Windows, das Sicherheitstools zur Überwachung der Systemaktivität verwenden.

Einige Routinen werden nur ausgeführt, wenn die Schadsoftware Produkte von Kaspersky oder Avast erkennt. Kaspersky erklärt jedoch, dass der betreffende Störmechanismus gegen die eigenen Lösungen nicht funktioniert.

Darüber hinaus verhindert der Treiber den Zugriff auf die Dateien des Bootkits. Wenn ein Benutzer versucht, sie zu öffnen, fängt er die Anfrage ab und startet stattdessen den Windows-Taschenrechner.

Spionage-Nutzlasten verwenden Cloud-Dienste und DLL-Laden

Der Treiber installiert außerdem Werkzeuge, die Fernzugriff und die weitere Ausführung von Schadsoftware ermöglichen.

Eine Nutzlast ist ein Fernzugriffstrojaner, der über Google Drive, OneDrive oder Yandex.Disk kommuniziert. Er kann .NET-Nutzlasten ausführen und Dateien zwischen dem kompromittierten Computer und seinen Betreibern übertragen.

Eine weitere Komponente namens OxiDLLRunner verwendet unterdessen DLL-Sideloading über ein Programm namens googleupdate.exe.

Sie entschlüsselt eine lokale Datei, um Shellcode und eine Rust-Nutzlast zu starten. Diese Nutzlast lädt anschließend DLL-Plugins von einem angreiferkontrollierten Server herunter und führt sie in separaten Threads aus.

Zusammen erweitern diese Komponenten den Angriff über den Startvorgang hinaus und ermöglichen fortgesetzte Spionage.

Installierte Updates schlossen die Schutzmaßnahmen nicht vollständig ab

Laut Kaspersky verwendeten alle identifizierten BlackX-Opfer eine vollständig aktualisierte Windows-Version. Allerdings hatten die Administratoren die zusätzlichen Secure-Boot-Sperrmaßnahmen nicht aktiviert, die zum Blockieren anfälliger Startkomponenten erforderlich sind.

Die Forscher erklären, dass die Installation der entsprechenden Updates allein das Vertrauen in das Zertifikat Windows Production PCA 2011 nicht automatisch widerrief.

Folglich konnten die Systeme weiterhin anfällige Komponenten laden, die mit diesem Zertifikat signiert waren, obwohl sie über aktuelle Windows-Patches verfügten.

Kaspersky vermutet, dass die Angreifer diese Lücke bewusst ausnutzten. Die Forscher argumentieren, dass Administratoren selten damit rechnen, nach der Installation eines Updates zusätzliche manuelle Sicherheitsschritte durchführen zu müssen.

Ablauf des Zertifikats blockiert anfällige Komponenten nicht automatisch

Das Zertifikat Windows Production PCA 2011 lief laut den Forschern am 19. Oktober 2026 ab.

Sie warnen jedoch davor, dass das Ablaufdatum allein betroffene Windows-Systeme nicht daran hindert, anfällige signierte Binärdateien zu laden. Administratoren müssen zusätzlich die entsprechenden Sperrmaßnahmen anwenden.

Microsoft stellt Anleitungen zum Widerruf anfälliger Windows-Bootmanager bereit. Die Ergebnisse verdeutlichen den Unterschied zwischen der Installation von Sicherheitsupdates und der Durchführung der zusätzlichen Schritte, die diese Updates erfordern.