UEFI Bootkit: Vom Labor in die Realität, mit Fokus auf Bootkitty und BlackLotus

UEFI-Bootkits haben sich innerhalb weniger Jahre von einem Laborkonzept zu einem echten Problem für Sicherheitsexperten und Hersteller entwickelt. In diesem Bereich verschwimmt die Grenze zwischen Machbarkeitsnachweis und tatsächlicher Bedrohung, wie Fälle wie BlackLotus oder die kürzliche Entdeckung von Bootkitty unter Linux deutlich belegen.

Dieser Artikel fasst die wichtigsten Informationen zusammen, die von Forschern und Unternehmen der Branche veröffentlicht wurden, und erläutert sie in klarer Sprache und mit technischen Details , wo diese einen Mehrwert bieten: vom ersten PoC im Jahr 2012 bis hin zu modernen Kampagnen, einschließlich Schwachstellen wie CVE-2024-7344 , die das Umgehen von Secure Boot ermöglichen, Ausweichtechniken, IoCs sowie Erkennungs- und Abhilfemaßnahmen, die in der realen Welt tatsächlich funktionieren.

Was ist ein UEFI-Bootkit und warum ist es so problematisch?

Ein UEFI-Bootkit ist ein Implantat, das vor dem Betriebssystem ausgeführt wird und den Bootvorgang steuern , Sicherheitsprüfungen deaktivieren und Komponenten mit erhöhten Berechtigungen laden kann. Da es auf einer so niedrigen Ebene arbeitet, kann es herkömmliche Antivirensoftware und sogar bestimmte „Secure Boot“-Maßnahmen umgehen , indem es Sicherheitslücken oder permissive Konfigurationen ausnutzt.

In der realen Welt wurden bereits persistente Implantate und Techniken in UEFI wie LoJax , MosaicRegressor oder MoonBounce beobachtet . Diese Meilensteine ​​zeigen, wie ein Akteur die Firmware übernehmen und kritische Bootphasen dominieren kann, was die forensische Analyse und die Behebung erschwert.

Zum Schutz von Windows setzt Microsoft mehrere Sicherheitsebenen ein: Secure Boot (UEFI validiert den Bootloader mit vertrauenswürdigen Zertifikaten), Trusted Boot (der Kernel validiert die anderen Komponenten), ELAM (Early Startup Antimalware, das Boot-Controller überprüft) und Measured Boot (TPM-Messungen und Remote-Attestierung). Diese Mechanismen bieten zwar nützliche Schutzmechanismen, sind aber nicht unfehlbar gegenüber Schwachstellen im UEFI-Ökosystem selbst oder zu weit gefassten Vertrauenskonfigurationen. Darüber hinaus kann Windows mit Credential Guard, BitLocker und WDAC weiter abgesichert werden, um das Risiko einer langfristigen Persistenz zu reduzieren.

Von PoCs zum echten Leben: Zeitleiste und Hauptakteure

Die Reise begann 2012 mit Andrea Allievis Proof of Concept (PoC ) für Windows auf UEFI, gefolgt von Projekten wie EfiGuard, Boot Backdoor und UEFI-Bootkit. Jahre vergingen, bis Fälle in freier Wildbahn wie ESPecter (ESET, 2021) und das FinSpy-Bootkit (Kaspersky, 2021) dokumentiert wurden. 2023 erschien BlackLotus , das erste UEFI-Bootkit, das Secure Boot auf vollständig aktualisierten Systemen umgehen konnte . In Laborumgebungen ist es üblich, Malware in einer virtuellen Maschine zu testen , um PoCs und Erkennungsmechanismen zu evaluieren, ohne Produktionsinfrastrukturen zu gefährden.

Eines war bis dahin konstant geblieben: Die Ziele waren ausschließlich Windows-Systeme . Diese Annahme wurde jedoch erschüttert, als im November 2024 eine UEFI-Anwendung namens bootkit.efi auf VirusTotal auftauchte . Die Analyse enthüllte ein Bootkit, von seinen Autoren Bootkitty genannt , das für Linux (Ubuntu) entwickelt wurde . Laut Telemetriedaten gibt es keine bestätigte tatsächliche Verbreitung; und die Autoren selbst, die mit dem koreanischen Schulungsprogramm Best of the Best (BoB) in Verbindung stehen , stellten klar, dass es sich um einen Machbarkeitsnachweis handelte , der die Aufmerksamkeit auf das Problem lenken sollte.

Die Bootkitty-Binärdatei ist mit einem selbstsignierten Zertifikat signiert . Daher kann sie nicht mit aktiviertem Secure Boot ausgeführt werden, es sei denn, die Zertifikate des Angreifers sind installiert . Ihre Logik veranschaulicht jedoch, wie ein Angreifer Komponenten des Loaders (GRUB) und des Linux-Kernels im Speicher patchen kann, um die Verifizierung zu umgehen.

Bootkitty im Detail: Artefakte, Kompatibilität und was es ändert

Das Bootkit enthält ungenutzte Funktionen, die ASCII-Art mit dem Namen „Bootkitty“ und einer Liste möglicher Autoren ausgeben. Es zeigt außerdem bei jedem Systemstart Textzeichenfolgen an und verweist in seiner Ausgabe sowie in einem zugehörigen Kernelmodul auf BlackCat , obwohl es keine Verbindung zur ALPHV/BlackCat-Ransomware hat. Dies liegt unter anderem daran, dass Bootkitty in C geschrieben ist , während ALPHV in Rust entwickelt wurde.

Die Kompatibilität ist eingeschränkt. Um die zu modifizierenden Funktionen zu bestimmen, verwendet es kodierte Byte-Muster (eine klassische Bootkit-Technik), doch die gewählten Muster decken nicht alle Kernel- oder GRUB-Versionen ab. Daher ist das Implantat nur in sehr wenigen Konfigurationen funktionsfähig und patcht zudem feste Offsets nach der Kernel-Dekomprimierung: Stimmen die Offsets nicht mit der Version überein, kann es zufällige Daten überschreiben und statt eines Kompromisses zu Abstürzen führen.

Der Bootvorgang beginnt mit dem Shim Bootkitty, der zunächst den SecureBoot- Status prüft und Hooks für zwei UEFI-Authentifizierungsprotokolle platziert: EFI_SECURITY2_ARCH_PROTOCOL.FileAuthentication und EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationState . In beiden Fällen wird die Ausgabe so angepasst, dass EFI_SUCCESS zurückgegeben wird , wodurch die Integritätsprüfung des PE-Images während der Pre-OS-Phase effektiv überschrieben wird.

Anschließend lädt Bootkitty ein legitimes GRUB von einem fest codierten Pfad auf dem ESP ( /EFI/ubuntu/grubx64-real.efi ), patcht es im Speicher und bindet wichtige Funktionen ein, bevor es ausgeführt wird.

Einbinden in GRUB und Entpacken des Linux-Kernels

Das Implantat verändert die Funktion `start_image` des GRUB -Moduls `peimage` , das für das Starten vorgeladener PE-Binärdateien (wie dem EFI-Stub des Kernels , `vmlinuz.efi/vmlinuz`) zuständig ist. Es nutzt aus, dass sich der Kernel bereits im Speicher befindet, und fügt einen Hook in die Routine ein, die das eigentliche Kernel-Image dekomprimiert (wahrscheinlich `zstd_decompress_dctx` , abhängig vom Build), sodass es nach der Dekomprimierung während des Kernelbetriebs gepatcht werden kann.

Es modifiziert außerdem die Funktion `grub_verifiers_open` , die entscheidet, ob die Integrität jeder geladenen Datei (Module, Kernel, Konfiguration usw.) überprüft wird. Der Hook kehrt sofort zurück, wodurch Signaturprüfungen vermieden werden . Die Anpassung an `shim_lock_verifier_init` ist hingegen verwirrend: Sie erzwingt ein strengeres Verifizierungsflag ( `GRUB_VERIFY_FLAGS_SINGLE_CHUNK` ), aber diese Funktion wird vom anderen Hook gar nicht aufgerufen und ist daher irrelevant.

Sobald der Kernel dekomprimiert ist, nimmt der Bootkitty-Code drei Änderungen im Speicher vor: Er überschreibt die Kernel -Versions-/Banner-Zeichenkette mit dem Text "BoB13"; er erzwingt, dass module_sig_check() 0 zurückgibt, damit der Kernel vorzeichenlose Module lädt ; und er ersetzt die erste Umgebungsvariable des Init- Prozesses , um LD_PRELOAD=/opt/injector.so /init am Anfang des Benutzerspeichers einzufügen.

Die Verwendung von LD_PRELOAD als Injektion ist eine gängige Taktik, um einem gemeinsam genutzten ELF-Objekt Priorität einzuräumen und Funktionen zu überschreiben. Die Zeichenkette weist hier eine Besonderheit auf (sie enthält neben LD_PRELOAD auch "/init"), was eher auf einen unfertigen Proof of Concept als auf eine ausgereifte Implementierung hindeutet. Die vermeintlich injizierten Binärdateien konnten nicht beobachtet werden, obwohl ein späteres Dokument eines Drittanbieters darauf hindeutet, dass sie lediglich zum Laden einer zusätzlichen Stufe verwendet werden.

Indikatoren, Symptome und ein einfaches Heilmittel

Ist Bootkitty vorhanden, können sichtbare Hinweise darauf vorliegen. Der Befehl `uname -v` zeigt die Kernelversion mit verändertem Text an, und der Befehl `dmesg` kann ebenfalls ein modifiziertes Banner anzeigen. Darüber hinaus lässt sich durch die Untersuchung von `/proc/1/environ` feststellen, dass der Prozess mit der PID 1 (init) mit `LD_PRELOAD` gestartet wurde – ein ungewöhnliches Zeichen auf legitimen Systemen.

In Labortests erscheint der Kernel nach dem Booten mit Bootkitty verfälscht , und eine weitere empirische Überprüfung auf Rechnern mit aktiviertem Secure Boot besteht darin, zu versuchen, ein unsigniertes Modul zu laden : Wenn das Laden spontan erlaubt ist, deutet dies darauf hin, dass module_sig_check gepatcht wurde.

Wenn das Bootkit durch Ersetzen der GRUB-Binärdatei durch eine Zwischendatei installiert wurde (beobachtetes Verhalten), besteht eine einfache Möglichkeit zur Wiederherstellung darin, die legitime GRUB-Datei von /EFI/ubuntu/grubx64-real.efi an ihren ursprünglichen Pfad /EFI/ubuntu/grubx64.efi zu verschieben , sodass shim sie ausführt und die Bootkette ohne das Implantat fortgesetzt wird.

BCDropper und BCObserver: Zusammenhängende Teile oder nur ein Zufall?

Neben Bootkitty wurde ein unsigniertes Kernelmodul mit dem Spitznamen BCDropper gefunden , das einige Gemeinsamkeiten mit dem Bootkit aufweist: BlackCat/blackcat- Zeichenketten in Metadaten und Debug-Pfaden sowie eine Dateiversteckfunktion , deren Präfixe "injector" enthalten (in Übereinstimmung mit der Variable LD_PRELOAD, die auf /opt/injector.so verweist).

BCDropper platziert eine eingebettete ELF-Datei ( BCObserver genannt) in /opt/observer und startet sie mit /bin/bash . Diese relativ einfache Komponente wartet, bis gdm3 aktiv ist, und lädt dann ein Kernelmodul aus /opt/rootkit_loader.ko mit finit_module , wobei sichergestellt wird, dass dies erst nach dem vollständigen Systemstart geschieht.

Obwohl es Anzeichen für einen Zusammenhang gibt, lässt sich nicht bestätigen, dass beide Elemente vom selben Autor stammen oder für die Zusammenarbeit konzipiert wurden. Erschwerend kommt hinzu, dass die in den Metadaten angegebene Kernel-Version ( 6.8.0-48-generic ) nicht einmal zu den vom Bootkit unterstützten Versionen gehört.

Zugehörige IoCs

Die folgenden Artefakte wurden mit den besprochenen Befunden in Verbindung gebracht. Ihr Wert liegt primär in ihrer Eignung als Referenzmaterial und für Laborzwecke:

BlackLotus und CVE-2022-21894: Der Meilenstein, der die Schleusen öffnete

BlackLotus wird seit 2022 zu einem Preis von rund 5.000 US-Dollar (zuzüglich zusätzlicher Kosten pro Update) vermarktet und beinhaltet Techniken zur Umgehung von VM- und Debug-Sicherheitsmaßnahmen , Geofencing zur Vermeidung bestimmter Länder (Armenien, Belarus, Kasachstan, Moldawien, Rumänien, Russland und Ukraine) und, am wichtigsten, die Ausnutzung von CVE-2022-21894 (Baton Drop), um Secure Boot zu umgehen und dauerhafte Sicherheit auf vollständig gepatchten Windows 10/11-Systemen zu erlangen.

Der von der Sicherheitscommunity beschriebene Ablauf umfasst eine erste Phase, in der die Schutzmechanismen des Betriebssystems deaktiviert , eine bestehende Schwachstelle in Secure Boot ausgenutzt und ein vom Angreifer kontrollierter Maschinenbesitzerschlüssel registriert wird . Nach mehreren Neustarts installiert das Implantat einen Kernel-Treiber und eine Komponente zum Herunterladen im Benutzermodus, um die Befehls- und Kontrollkommunikation sowie zusätzliche Nutzdaten zu verwalten.

Zur proaktiven Verteidigung hat die Community operative Regeln veröffentlicht. SOC Prime bietet beispielsweise Sigma-Erkennungen, die nach der verdächtigen Erstellung von Firmware-Dateien in System32 durch Nicht-Systemprozesse oder der Deaktivierung von HVCI über die Registry suchen. Diese Signale, die MITRE ATT&CK zugeordnet sind (z. B. T0857, T1562, T1112), helfen bei der Suche nach anomalen Aktivitäten , die häufig mit Bootkits einhergehen. Es gibt außerdem praktische Anleitungen zur Erkennung schädlicher Prozesse mit dem Process Explorer in Windows-Umgebungen.

CVE-2024-7344: Laden nicht vertrauenswürdiger UEFI-Binärdateien über „reloader.efi“

Im Jahr 2024 wurde eine besonders schwerwiegende Sicherheitslücke, CVE-2024-7344 , entdeckt, die mehrere mit dem Microsoft Corporation UEFI CA 2011- Zertifikat signierte Recovery-Suites betrifft . Die Ursache liegt in der Verwendung eines benutzerdefinierten PE-Loaders in der Anwendung UEFI reloader.efi anstelle der sicheren LoadImage/StartImage- APIs . Die Binärdatei entschlüsselt und führt Inhalte aus einer cloak.dat- Datei aus, ohne die Signaturen gemäß der Secure-Boot- Richtlinie zu überprüfen.

Die Sicherheitslücke beschränkt sich nicht auf Rechner mit installierter Software. Angreifer mit erhöhten Rechten können die anfällige Binärdatei in die ESP-Partition (EFI-Partition) jedes Systems einspielen, das auf Microsofts UEFI-Zertifizierungsstelle eines Drittanbieters basiert, und so ein unsigniertes UEFI beim Systemstart ausführen. Betroffen waren unter anderem Software-Suiten von Howyar, Greenware, Radix, SANFONG, Wasay, CES und Signal Computer, die am 14. Januar 2025 gepatcht und zurückgerufen wurden.

Um den Schutz in PowerShell mit erhöhten Berechtigungen und unter Linux (LVFS/dbxtool) zu überprüfen :

# ¿El sistema confía en la UEFI CA 2011 de Microsoft? (posible exposición)
::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'

# Revocación instalada (64 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'

# Revocación instalada (32 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

# Linux (dbxtool)
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

Dieser Fall entfacht die Debatte um die Vertrauenskette neu : Microsoft verwendet zwei Zertifikate, die auf UEFI-Systemen für Privat- und Geschäftskunden weit verbreitet sind ( Windows Production CA 2011 und UEFI-Zertifikat von Drittanbietern 2011 ). Geplant ist die Migration auf Zertifikate des Standards 2023 , infolge von Vorfällen wie BlackLotus und der Verbreitung anfälliger, vor Jahren signierter Bootloader. Auf Secured-Core -Systemen ist das UEFI-Zertifikat von Drittanbietern in der Regel standardmäßig deaktiviert.

Praktischer Schutz und Anpassung von Secure Boot

Neben der Anwendung von UEFI-Sperren und der Aktualisierung von Firmware/Betriebssystem ( Windows Update und LVFS) gibt es Maßnahmen, die die Angriffsfläche verringern: Kontrolle des Zugriffs auf den ESP mit Sicherheitsregeln, Anpassung von Secure Boot , um das Vertrauen auf das Notwendige zu beschränken (gemäß Richtlinien wie denen der NSA ), und Einsatz von TPM-Attestierung zur Remote-Validierung des Boot-Status anhand von Referenzwerten.

Unter Windows bietet die Kombination aus Secure Boot, Trusted Boot, ELAM und Measured Boot mehrstufige Schutzmechanismen: Validierung des Bootloaders, Überprüfung der Boot-Treiber vor allen anderen Systemen und eine TPM -signierte Registrierung , die es der Firewall ermöglicht, „saubere“ Rechner von solchen mit Abweichungen zu unterscheiden. In verwalteten Umgebungen verkürzt dies die Erkennungs- und Eindämmungszeit.

Unter Linux ist es neben Widerrufen und ESP-Kontrolle ratsam, Signale wie LD_PRELOAD im Init- Prozess , den veränderten Zustand des Kernels zu überwachen und Modulladeereignisse (z. B. finit_module ) mit ungewöhnlichen Pfaden ( /opt/*.ko ) zu korrelieren, um frühzeitige Persistenzversuche zu erkennen.

Tools, Abdeckung und MITRE ATT&CK

Laut ESET ist das Unternehmen der einzige der 20 umsatzstärksten Anbieter von Endgeräten, der einen UEFI-Firmware-Scanner in seine Geräteschutzlösungen integriert. Andere Hersteller bieten zwar UEFI-bezogene Technologien an, deren Zweck deckt sich jedoch nicht immer mit der direkten Firmware-Analyse . Da UEFI-Angriffe, obwohl sporadisch, vollständige Kontrolle und nahezu absolute Persistenz ermöglichen, kann die Investition in diese Schutzebene entscheidend sein.

Im Hinblick auf MITRE ATT&CK passen die beobachteten Verhaltensweisen zu mehreren Techniken: Pre-OS Boot: Bootkit (T1542.003) , Shared Modules/LD_PRELOAD (T1129) , Malware- Entwicklung (T1587.001) und Verwendung von Zertifikaten (T1587.002) , zusätzlich zu Rootkit (T1014) , Beeinträchtigung der Verteidigung (T1562) und Verstecken von Artefakten (T1564) im Falle von Kernelmodulen, die sich selbst verstecken.

• T1542.003: Bootkit auf dem ESP für die Persistenz vor dem Betriebssystem.
• T1129: Vorladen mit LD_PRELOAD im Init-Prozess.
• T1014: Kernelmodule mit Rootkit-Funktionalität.
• T1562 / T1564: Prüfungen deaktivieren und vor dem System verbergen.

Linux ist nicht unverwundbar: Der Bootkitty-Fall und neue Namen auf dem Radar

Jahrelang wurde in der öffentlichen Wahrnehmung die größere Verbreitung von Windows dem vermeintlichen „Undurchdringlichsein“ von macOS oder Linux gegenübergestellt . Die Realität ist differenzierter: Ihre Geschäftsmodelle und Marktanteile machen sie zwar zu unterschiedlichen Zielen, aber nicht immun. Das Aufkommen von Bootkitty für Linux zeigt, dass das Know-how zur Entwicklung von Bootkits auch für dieses Ökosystem vorhanden ist, auch wenn es sich in diesem konkreten Fall um einen akademischen Machbarkeitsnachweis mit begrenzter Unterstützung handelt.

Es gibt sogar Berichte über eine Ransomware-Variante namens HybridPetya , die angeblich UEFI-Bootkit-Funktionen nutzt. Im Jahr 2025 aus Polen auf VirusTotal hochgeladene Beispiele deuten auf eine aktuelle Entwicklung hin; diese sollten jedoch mit Vorsicht behandelt werden, bis unabhängige Analysen und gesicherte Zuordnungen vorliegen.

Wichtig ist, zu verinnerlichen, dass die Verteidigung die gesamte Boot-Kette abdecken, das standardmäßige Vertrauen in nicht verwendete Signaturen von Drittanbietern minimieren, die EFI-Partition überwachen und nützliche Telemetriedaten (manipulierter Kernel, Modulereignisse, Änderungen in GRUB-Verifizierern oder sensiblen UEFI-Variablen) konsolidieren muss, um rechtzeitig erkannt zu werden.

Die aktuelle UEFI-Risikolandschaft umfasst Schulungsprojekte (Proof-of-Concepts, PoCs) , als Dienstleistung angebotene Bootkits und Schwachstellen in signierten Komponenten. Werden diese nicht umgehend widerrufen, ermöglichen sie die Ausführung nicht vertrauenswürdiger Programme vor dem Betriebssystemstart . Die Aktualisierung von Firmware und Sperrlisten, die Einschränkung des Vertrauenskreises und die Überwachung des Electronic Service Providers (ESP) stärken die Verteidigungsposition gegen diese Bedrohungen erheblich.

In Verbindung stehender Artikel:

So sichern Sie Windows mit Credential Guard, BitLocker, AppLocker, Device Guard und WDAC

Holger

Leidenschaftlicher Autor über die Welt der Bytes und der Technologie im Allgemeinen. Ich liebe es, mein Wissen durch Schreiben zu teilen, und genau das werde ich in diesem Blog tun und Ihnen die interessantesten Dinge über Gadgets, Software, Hardware, technologische Trends und mehr zeigen. Mein Ziel ist es, Ihnen dabei zu helfen, sich auf einfache und unterhaltsame Weise in der digitalen Welt zurechtzufinden.