BlackX: APT41-Bootkit nutzt fehlende Secure-Boot-Sperrungen
Der UEFI-Bootkit BlackX nutzt die alte Lücke Baton Drop auch auf vollständig gepatchten Windows-Systemen. Grund ist die fehlende manuelle Sperrung des Zertifikats Windows Production PCA 2011 in der DBX. Admins sollten den Stand prüfen und die Sperrung geplant nachholen.
Kaspersky hat am 22. Oktober 2026 einen UEFI-Bootkit namens BlackX beschrieben, der Secure Boot auch auf vollständig gepatchten Windows-Rechnern aushebelt. Der Grund ist kein neuer Fehler, sondern eine nie abgeschlossene Härtung: Das Zertifikat „Windows Production PCA 2011“, mit dem die verwundbaren Boot-Komponenten signiert sind, steht auf vielen Systemen nicht in der Sperrliste DBX. Diese Sperrung setzt Windows Update nicht automatisch, Admins müssen sie selbst auslösen.
BlackX ist ein Werkzeug für Persistenz und das Ausschalten von Schutzsoftware, kein Einfallstor. Die Angreifer brauchen bereits Administratorrechte oder physischen Zugriff. Wer Secure Boot nicht nutzt, ist von dieser Umgehung nicht betroffen, hat aber ohnehin keinen Schutz auf dieser Ebene. Für die meisten Unternehmen ist das kein Notfall für heute Nacht, aber ein Auftrag: den DBX-Stand prüfen und die Sperrung in einem geplanten, getesteten Rollout nachholen.
Was ist passiert?
Laut dem Securelist-Bericht von Kaspersky GReAT kam BlackX Anfang 2026 bei Angriffen auf diplomatische Einrichtungen in Tadschikistan, Usbekistan und Turkmenistan zum Einsatz. Kaspersky ordnet die Kampagne mit mittlerer Sicherheit der chinesischen Gruppe APT41 zu. Der Bootkit ähnelt BlackLotus, dessen Existenz ESET im März 2023 bestätigte, und nutzt wie dieser die Lücke Baton Drop (CVE-2022-21894).
Nach dem Einbruch ins Netz und dem Erlangen von Adminrechten legten die Angreifer ein Installationsprogramm und eine verschlüsselte Datei ab. Der Exploit installiert eigene Machine Owner Keys, damit lassen sich beliebige EFI-Dateien laden. Der Bootkit schleust dann einen signierten Treiber in den Windows-Kernel, der Callbacks und ETW-Provider von Sicherheitsprodukten manipuliert, die eigenen Dateien verbirgt und Spionage-Nutzlasten nachlädt, darunter einen RAT mit Steuerung über Cloud-Speicher.
Die Pointe des Berichts: Die infizierten Rechner waren vollständig gepatcht. Microsofts Gegenmaßnahme sieht vor, „Windows Production PCA 2011“ in die DBX aufzunehmen. Dafür muss ein Registry-Wert unter HKLM\SYSTEM\CurrentControlSet\Control\Secureboot gesetzt und die geplante Aufgabe Secure-Boot-Update ausgeführt werden. Die von Microsoft angekündigte Enforcement-Phase, die das automatisch erledigt, hat noch kein Datum. Das Zertifikat ist laut Kaspersky am 19. Oktober 2026 abgelaufen, das verhindert das Laden der alten Bootmanager aber nicht, solange es nicht gesperrt ist.
Wer ist betroffen?
Betroffen sind Windows-Geräte mit aktiviertem Secure Boot, auf denen die PCA-2011-Sperrung nicht angewendet wurde. Kaspersky geht davon aus, dass nur wenige Organisationen die Bedeutung der manuellen Aktivierung erkannt haben. Die beobachteten Ziele waren diplomatische Stellen in Zentralasien. Hinweise auf breite Angriffe gegen Unternehmen in Europa enthält der Bericht nicht.
Wie kritisch ist das?
Technisch geht es um die Umgehung von Secure Boot und dauerhafte Einnistung unterhalb des Betriebssystems, nicht um Remote Code Execution. Ein Angreifer mit Adminrechten kann so schon vor dem Start von Windows eingreifen und Schutzsoftware blenden. Gesichert ist der Einsatz in gezielten Angriffen. Offen ist, ob weitere Gruppen den Ansatz übernehmen. Die Sperrung selbst ist nicht ohne Risiko: Microsoft warnt vor Geräten, deren Firmware DB- oder DBX-Updates nicht verträgt, vor BitLocker-Wiederherstellungsabfragen und davor, dass ältere Boot- und Wiederherstellungsmedien danach nicht mehr starten.
Was sollten Admins jetzt tun?
- Den DBX-Stand inventarisieren: Laut Microsoft liefert
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'in einer Admin-PowerShellTrue, wenn die Sperrung aktiv ist. Alternativ Ereignis 1037 im Ereignisprotokoll prüfen. - Vor der Umstellung BitLocker-Wiederherstellungsschlüssel sichern und Boot-, PXE- und Wiederherstellungsmedien auf aktuelle Stände bringen.
- Die Schritte aus Microsofts Anleitung zu den Bootmanager-Sperrungen zunächst auf je einem Gerät pro Hardwaremodell testen, dann gestaffelt ausrollen.
- Rechner mit sensiblen Rollen zuerst härten, etwa Admin-Arbeitsplätze, Domain Controller und Systeme der Geschäftsleitung.
- EFI-Partitionen auf unbekannte Dateien und Bootmanager prüfen und EDR-Meldungen zu manipulierten Kernel-Callbacks oder ETW-Providern ernst nehmen.
- Dual-Boot-Systeme und ältere Hardware gesondert betrachten, denn hier kann die Sperrung den Start verhindern.
Einordnung für Unternehmen
Für ein typisches KMU ist BlackX kein akutes Szenario, die Kampagne zielt auf diplomatische Organisationen. Der Bericht zeigt aber ein strukturelles Problem: Ein installiertes Update bedeutet nicht automatisch, dass die Lücke geschlossen ist. Wer die Secure-Boot-Umstellung auf die 2023er Zertifikate ohnehin plant oder schon umgesetzt hat, sollte die DBX-Sperrung im selben Projekt mit erledigen und dokumentieren.
Passende Anleitungen auf S-EDV
- Secure Boot: 2023er UEFI-Zertifikate auf Windows Server und VMware einspielen: Grundlagen zu DB, DBX und Registry-Schaltern.
- Secure-Boot-Zertifikate laufen ab: Hintergrund zum Zertifikatswechsel bei Windows.
- Secure-Boot-Zertifikatsablauf: Was IT-Admins wissen müssen: Checkliste für den Rollout.
