BlackX Bootkit: Secure Boot fällt trotz vollständigem Patch

Hinweis: Dieser Beitrag wurde mit KI-Unterstützung erstellt und automatisiert veröffentlicht.

Das BlackX Bootkit hebelt Secure Boot auf Windows-Rechnern aus, die vollständig gepatcht sind – weil der entscheidende Teil des Patches erst manuell scharfgeschaltet werden muss. Kasperskys Forschungsteam GReAT hat die Schadsoftware am 22. Oktober 2026 beschrieben. Der Fall ist unangenehm, weil er eine verbreitete Annahme widerlegt: Updates installieren reicht hier nicht.

Was das BlackX Bootkit tut

BlackX nutzt die Lücke „Baton Drop“ (CVE-2022-21894) aus. Damit trägt es eigene Machine Owner Keys ein und lädt anschließend beliebige EFI-Dateien. Secure Boot prüft weiter brav Signaturen – nur eben gegen einen Schlüssel der Angreifer. Der Ablauf gleicht dem Bootkit BlackLotus, das 2022 in einem Hackerforum angeboten wurde. Kaspersky hält es für möglich, dass die Täter BlackLotus rückentwickelt oder dessen Quellcode gekauft haben.

Installiert wird BlackX erst, nachdem die Angreifer schon Administratorrechte besitzen. Dafür legen sie zwei Dateien ab: eine Installer-Datei und eine RC4-verschlüsselte Datei ohne Endung, die alle Bausteine enthält. Der Installer selbst enthält keine verdächtigen Zeichenketten. Das erschwert die Analyse.

Danach startet ein Kernel-Treiber. Er deaktiviert Callbacks von Sicherheitsprodukten, manipuliert ETW-Provider und schützt die eigenen Dateien: Wer sie öffnen will, bekommt stattdessen einen Verweis auf den Windows-Rechner. Als zweite Stufe fand Kaspersky einen RAT, der Google Drive, OneDrive und Yandex.Disk als Steuerkanal missbraucht, sowie eine weitere Komponente, die per DLL-Sideloading über eine legitime, in googleupdate.exe umbenannte Programmdatei startet – im Original jcef_helper.exe, also keine echte Google-Updater-Komponente. Die Spionagekampagne traf Anfang 2026 diplomatische Einrichtungen in Tadschikistan, Usbekistan und Turkmenistan. Kaspersky ordnet sie der Gruppe APT41 zu – ausdrücklich nur mit mittlerer Zuversicht.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Ich werte aus, ob du den Newsletter öffnest und Links anklickst, um ihn zu verbessern. Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Der eigentliche Skandal: der Patch wirkt nicht von allein

Die betroffenen Rechner waren aktuell gepatcht. Der Patch, der die Baton-Drop-Komponenten entschärft, sperrt laut Kaspersky das Zertifikat „Windows Production PCA 2011“, mit dem die angreifbaren Boot-Komponenten signiert sind – formal gehört diese Sperre zu Microsofts Maßnahmenprogramm KB5025885 (CVE-2023-24932), das die anfälligen Boot-Manager mitabdeckt. Diese Sperre wird aber nicht automatisch wirksam. Sie muss manuell ausgelöst werden – über einen Registry-Wert unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot und eine geplante Aufgabe namens Secure-Boot-Update. Microsoft hat das so gebaut, weil eine automatische Sperre Dual-Boot-Systeme lahmlegen könnte. Die von Microsoft angekündigte Erzwingungsphase ist laut Kaspersky bis heute nicht umgesetzt. Das Zertifikat ist am 19. Oktober 2026 abgelaufen – das allein hindert die angreifbaren Dateien jedoch nicht am Laden.

Was das für dich bedeutet

Nach 25 Jahren IT und vielen Patch-Zyklen ist das für mich der lehrreichste Teil der Geschichte. Unsere ganze Patch-Praxis beruht auf einer stillen Annahme: Update eingespielt, Lücke zu. Genau diese Annahme gilt hier nicht. Ein zweistufiger Patch, dessen zweite Stufe in einem Hersteller-Blogbeitrag steht, wird in der Praxis fast nie zu Ende gebracht. In kaum einem Compliance-Bericht taucht die Unterscheidung „Update installiert“ gegen „Sperre aktiv“ überhaupt auf. Abfragbar ist sie – nur fragt sie fast niemand ab. Dazu kommt: Kaspersky verkauft hier auch die eigene Schutzlösung mit. Der Befund zum Patch bleibt davon unberührt, denn Microsoft beschreibt den manuellen Schritt selbst.

Panik ist trotzdem unangebracht. BlackX ist kein Einstiegsweg, sondern eine Technik zum dauerhaften Bleiben: Die Angreifer brauchen vorher Administratorrechte. Für Privatanwender ist das Risiko daher gering. Relevant ist es dort, wo ein Rechner als Sprungbrett dient und eine Neuinstallation den Angreifer eigentlich loswerden soll – denn ein Bootkit übersteht genau das.

Konkret zu tun

• Prüfe, ob die Sperre wirklich greift – nicht, ob die Aufgabe existiert. Die geplante Aufgabe Secure-Boot-Update liegt auf gepatchten Systemen ohnehin vor und beweist nichts. Prüfe stattdessen den Zustand selbst, per PowerShell als Administrator: [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' und [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'. Beides muss True liefern. Kommt beim zweiten Befehl False, ist Baton Drop auf diesem System weiter ausnutzbar – trotz aktueller Updates.
• Arbeite Microsofts Anleitung KB5025885 geplant ab (Quelle unten), nicht hektisch. Erst Dual-Boot- und Wiederherstellungsmedien erfassen, dann in Wellen ausrollen. Veraltete Boot- oder WinPE-Medien starten nach der Sperre nicht mehr.
• Nimm Treiber-Manipulation als Alarm ernst. Wenn Callbacks oder ETW-Provider einer Sicherheitslösung plötzlich stumm sind, ist das kein Software-Fehler, sondern ein Befund.
• Behandle Firmware-Befall als Totalverlust des Vertrauens. Ohne saubere, offline gehaltene Backups bleibt nach einem Bootkit nur Raten. Wie solche Backups aussehen, habe ich im Ratgeber zu verschlüsselten USB-Sticks und externen SSDs zusammengefasst.

Die allgemeine Lehre: Bei jedem Patch, der laut Hersteller „zusätzliche Schritte“ verlangt, gehört ein Haken in die eigene Checkliste. Ein ähnlicher Fall war die Windows-Shell-Lücke CVE-2026-96951, bei der eine Schutzfunktion ebenfalls leiser ausfiel als erwartet.

Quellen

• Securelist (Kaspersky GReAT): New BlackX UEFI bootkit exploiting Baton Drop
• BleepingComputer: BlackX UEFI bootkit exploits Baton Drop flaw to bypass Secure Boot
• Microsoft KB5025885: Anleitung zur Verwaltung der Boot-Manager-Sperren
• Microsoft: Revoking vulnerable Windows boot managers (Hintergrund)
• NVD: CVE-2022-21894 – Secure Boot Security Feature Bypass (CVSS 4.4; von Microsoft „Baton Drop“ genannt)