Bootkit

Ein Bootkit ist eine spezialisierte Form von Schadsoftware, die sich in der Bootkette eines Systems einnistet — also in jenen Komponenten, die zwischen dem Einschalten der Hardware und dem Start des Betriebssystems ausgeführt werden. Typische Persistenzorte sind der Bootloader auf der EFI System Partition (ESP), Treiber im DXE-Stadium der UEFI-Firmware oder direkt der SPI-Flash-Baustein des Mainboards. Weil ein Bootkit damit vor dem Betriebssystem läuft, kann es Sicherheitsmechanismen wie Defender, BitLocker-Integritätsprüfungen oder HVCI gezielt deaktivieren oder unterlaufen, noch bevor diese überhaupt geladen werden.

Bootkit vs. Rootkit: Wo liegt der Unterschied?

Beide Begriffe werden in der Praxis oft synonym verwendet, beschreiben aber unterschiedliche Konzepte. Ein klassisches Rootkit operiert im Kontext eines bereits gestarteten Betriebssystems — typischerweise im Kernel — und manipuliert dort Datenstrukturen, um Prozesse, Dateien oder Netzwerkverbindungen zu verstecken. Ein Bootkit setzt eine Ebene tiefer an und sichert seine Persistenz dort, wo das Betriebssystem noch keine Kontrolle hat.

In der Praxis ist die Grenze fließend: Viele moderne Implants kombinieren beide Ebenen — ein Bootkit-Loader sorgt für Persistenz, ein Kernel-Komponent übernimmt nach dem OS-Start die operative Arbeit.

Persistenz in ESP und Firmware

Die Wahl des Persistenzortes bestimmt, wie tief ein Bootkit verankert ist und wie aufwendig seine Entfernung wird. ESP-basierte Bootkits ersetzen oder ergänzen .efi-Dateien auf der EFI System Partition und manipulieren die Boot Configuration Data (BCD), sodass beim nächsten Start die kompromittierte Binary geladen wird. Sie sind vergleichsweise einfach zu installieren — Administrator-Rechte genügen — aber auch durch ein Re-Image der Disk wieder entfernbar.

Firmware-basierte Implants nisten sich direkt im SPI-Flash der Hauptplatine ein und überleben sowohl Festplattenwechsel als auch komplette OS-Neuinstallationen. Ihre Entfernung erfordert typischerweise einen externen SPI-Programmer oder ein vom Hersteller signiertes Firmware-Reflash — Maßnahmen, die in den meisten KMU-Umgebungen nicht ohne externe Unterstützung umsetzbar sind.

Secure-Boot-Bypass: LoJax, MoonBounce, BlackLotus

Die öffentlich bekannten UEFI-Implants markieren jeweils eine neue Eskalationsstufe und zeigen, dass Secure Boot allein keine ausreichende Schutzmaßnahme ist:

BlackLotus ist insofern eine Zäsur, als es das erste kommerziell verfügbare Bootkit war, das Secure Boot auf einem vollständig aktuellen Windows 11 ausgehebelt hat — über das sogenannte Bring-Your-Own-Vulnerable-Binary-Vorgehen, bei dem eine alte, weiterhin signierte Bootloader-Version auf die ESP kopiert wird. Details zur Mechanik und der mehrphasigen Microsoft-Revokation unter CVE-2023-24932 haben wir im Artikel zu BlackLotus und Secure Boot zusammengefasst.

Detection: Measured Boot und TPM-Attestation

Klassische lokale Erkennung funktioniert bei Bootkits nur eingeschränkt, weil das kompromittierte System selbst die Telemetriequelle ist. Robust ist allein der externe Vergleich kryptografischer Messwerte. Beim sogenannten Measured Boot misst die Firmware Hashes jeder geladenen Komponente — Boot Manager, Bootloader, Kernel-Treiber — und legt sie in den Platform Configuration Registers (PCR) des TPM ab.

Diese PCR-Werte lassen sich anschließend an einen externen Attestation-Service senden (etwa Microsoft Azure Attestation oder Intune Compliance) und gegen einen bekannten Goldstand vergleichen. Weicht ein PCR ab — typischerweise PCR[0,2,4,7] — ist das ein starkes Indiz für eine manipulierte Bootkette. In der Praxis kombinieren wir in Assessments diese Attestierung mit dem Offline-Scan der ESP, dem Abgleich der NVRAM-Variable MokList und der Prüfung, ob HVCI über die Registry deaktiviert wurde — keine einzelne Quelle ist beweisend, aber die Kombination liefert belastbare Verdachtsmomente.

Defense: HVCI, VBS und im Ernstfall Re-Image

Auch ein erfolgreich installiertes Bootkit muss letztlich Code im Kernel ausführen, um nutzbar zu sein. Genau hier setzen Hypervisor-basierte Schutzmechanismen an. Virtualization-Based Security (VBS) und Hypervisor-Enforced Code Integrity (HVCI) verlagern die Code-Integritätsprüfung in eine isolierte VTL1-Umgebung, die selbst ein Kernel-Treiber des Bootkits nicht ohne Weiteres erreicht. In Kombination mit aktivem Secure Boot, einem TPM 2.0 und der Härtung über Secured-Core entsteht eine Vertrauenskette, die heutige Bootkit-Generationen praktisch nicht mehr nutzbar macht.

Bei einer bestätigten Infektion ist die Empfehlung der NSA aus dem BlackLotus Mitigation Guide eindeutig und gilt analog für andere ESP-basierte Bootkits: ESP wipen, Disk neu partitionieren, frisches Image aufspielen. Manuelles Cleanup ist riskant, weil das Bootkit Dateien sperren oder wieder zurückschreiben kann. Bei Verdacht auf ein Firmware-Implant reicht selbst das Re-Image nicht — hier ist ein Firmware-Reflash über den Herstellerprozess oder ein Hardware-Tausch notwendig.

Relevanz für KMUs

Bootkits gelten lange als reines APT-Werkzeug, doch BlackLotus hat die Eintrittshürde drastisch gesenkt: Das Implant wurde in Untergrundforen für rund 5.000 USD verkauft und ist damit auch für kommerziell motivierte Angreifer erschwinglich. Für den Mittelstand bedeutet das in der Praxis drei Maßnahmen: Secure Boot und TPM 2.0 auf der gesamten Geräteflotte verifizieren, HVCI/VBS per GPO oder Intune erzwingen und — sofern Conditional Access bereits genutzt wird — TPM-Attestation als Bedingung für den Zugriff auf Unternehmensressourcen aktivieren. Wer bei der nächsten Hardwarebeschaffung auf Secured-Core-zertifizierte Geräte achtet, bekommt viele dieser Härtungen ab Werk konfiguriert.