Analyse der UEFI-Bootkit-Persistenz

Was macht Analyse der UEFI-Bootkit-Persistenz?

Verwendungszweck

• Ein kompromittiertes System stellt nach einer Neuinstallation des Betriebssystems oder einem Austausch der Festplatte erneut eine C2-Kommunikation her
• Secure Boot wurde manipuliert, deaktiviert oder zeigt unerwartete Einträge von Machine Owner Keys (MOKs)
• Die Integritätsprüfung der Firmware schlägt im Vergleich zu herstellerseitigen Baselines fehl
• Die Speicherforensik zeigt Rootkit-Komponenten, die während der frühen Bootphase geladen werden
• Untersuchung von Kampagnen fortschrittlicher persistenter Bedrohungen (APTs), die bekanntermaßen UEFI-Implantate einsetzen
• Überprüfung der Firmware-Sicherheitslage für die Härtung von Endpunkten in Unternehmen

Nicht verwenden für standardmäßige MBR-basierte Bootkits auf Legacy-BIOS-Systemen ohne UEFI; stattdessen die Analyse von MBR/VBR-Bootkits verwenden.

Voraussetzungen

• chipsec-Framework zum Auslesen von SPI-Flash, zur Inspektion von UEFI-Variablen und für Firmware-Sicherheitsmodule
• UEFITool / UEFIExtract zum Parsen von Firmware-Volumes und Extrahieren von DXE-Treibern
• Python 3.8+ mit den Modulen struct, hashlib, subprocess und os
• Bootbarer Linux-Live-USB für die Offline-Analyse (kein Ausführen des kompromittierten Betriebssystems)
• Volatility 3 für die Speicherforensik von Bootphasen-Artefakten
• YARA mit UEFI-Malware-Regelsätzen für die mustergesteuerte Erkennung
• Zugriff auf herstellerseitige Firmware-Baselines für den Integritätsvergleich

Arbeitsablauf

Schritt 1: SPI-Flash-Firmware auslesen

Die UEFI-Firmware vom SPI-Flash-Chip für die Offline-Analyse sichern:

# Verwenden von chipsec zum Auslesen des SPI-Flash-Inhalts
python chipsec_util.py spi dump firmware_dump.rom

# Verwenden von flashrom als Alternative
flashrom -p internal -r firmware_dump.rom

# Integrität des Dumps überprüfen
sha256sum firmware_dump.rom

# Informationen zum SPI-Flash-Descriptor lesen
python chipsec_util.py spi info

# Zugriffsberechtigungen für SPI-Flash-Regionen prüfen
python chipsec_main.py -m common.spi_access

# Überprüfen, ob der BIOS-Schreibschutz aktiviert ist
python chipsec_main.py -m common.bios_wp

# SPI-Flash-Controller-Sperre prüfen
python chipsec_main.py -m common.spi_lock

Schritt 2: UEFI-Variablen inspizieren

UEFI-Variablen aufzählen und auf nicht autorisierte Änderungen analysieren:

# Alle UEFI-Variablen auf einem laufenden System auflisten
python chipsec_util.py uefi var-list

# UEFI-Variablen aus einem SPI-Flash-Dump auflisten
python chipsec_util.py uefi var-list-spi firmware_dump.rom

# Bestimmte Secure-Boot-Variablen lesen
python chipsec_util.py uefi var-read SecureBoot 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read SetupMode 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read PK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read KEK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read db D719B2CB-3D3A-4596-A3BC-DAD00E67656F

# UEFI-Schlüsseldatenbanken zur Analyse ausgeben
python chipsec_util.py uefi keys

# Secure-Boot-Konfigurationsmodul prüfen
python chipsec_main.py -m common.secureboot.variables

Schritt 3: EFI-Systempartition (ESP) analysieren

Die ESP auf nicht autorisierte oder veränderte Boot-Komponenten überprüfen:

# ESP mounten (üblicherweise die erste FAT32-Partition, ~100-500 MB)
mkdir /mnt/esp
mount /dev/sda1 /mnt/esp

# Alle Dateien auf der ESP mit Zeitstempeln auflisten
find /mnt/esp -type f -exec ls -la {} \;

# Nach BlackLotus-Indikatoren suchen – benutzerdefiniertes Verzeichnis unter ESP:/system32/
ls -la /mnt/esp/system32/ 2>/dev/null

# Signatur des Windows-Boot-Managers überprüfen
sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi

# Alle EFI-Binärdateien hashen und mit bekannten korrekten Werten vergleichen
find /mnt/esp -name "*.efi" -exec sha256sum {} \;

# Nach nicht autorisierten .efi-Dateien außerhalb der Standardverzeichnisse suchen
find /mnt/esp -name "*.efi" | grep -v "Microsoft\|Boot\|ubuntu\|grub"

# Nach von BlackLotus eingeschleustem grubx64.efi suchen
find /mnt/esp -name "grubx64.efi" -exec sha256sum {} \;

# MeasuredBoot-Protokolle auf Anomalien untersuchen (Windows)
# Protokolle unter C:\Windows\Logs\MeasuredBoot\

Schritt 4: Firmware auf bekannte Bootkit-Signaturen scannen

Den Firmware-Dump auf bekannte UEFI-Malware-Muster analysieren:

# Alle Firmware-Module mit UEFIExtract extrahieren
UEFIExtract firmware_dump.rom all

# Firmware-Modul-Whitelist aus der Hersteller-Baseline generieren
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom

# Aktuelle Firmware mit der Whitelist vergleichen
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom

# Firmware mit UEFI-spezifischen YARA-Regeln scannen
yara -r uefi_bootkits.yar firmware_dump.rom

# Extrahierte Module einzeln scannen
find firmware_dump.rom.dump -name "*.efi" -exec yara -r uefi_bootkits.yar {} \;

# Nach modifiziertem CORE_DXE-Modul suchen (Ziel von MoonBounce, CosmicStrand)
# GUID und Hash mit Hersteller-Baseline vergleichen

Schritt 5: Secure-Boot-Bypass-Mechanismen erkennen

Auf bekannte Secure-Boot-By pass-Techniken prüfen:

# Prüfen, ob Secure Boot aktiviert ist
python chipsec_main.py -m common.secureboot.variables

# SMM-Schutz (System Management Mode) überprüfen
python chipsec_main.py -m common.smm

# SMM-BIOS-Schreibschutz prüfen
python chipsec_main.py -m common.bios_smi

# Unter Windows – Boot-Konfiguration auf Bypass-Indikatoren prüfen
bcdedit /enum firmware
bcdedit /v

# Nach testsigning/nointegritychecks/debug-Flags suchen
bcdedit | findstr /i "testsigning nointegritychecks debug"

# Überprüfen, ob HVCI (Hypervisor-erzwungene Code-Integrität) nicht deaktiviert ist
# BlackLotus setzt HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled

# Secure-Boot-Status über PowerShell prüfen
# Confirm-SecureBootUEFI gibt True zurück, wenn ordnungsgemäß aktiviert

Schritt 6: Integritätsprüfung der Boot-Kette durchführen

Jede Komponente der Boot-Kette von der Firmware bis zum Kernel überprüfen:

# Firmware-Integrität anhand des Hersteller-Hashes prüfen
sha256sum firmware_dump.rom
# Mit dem vom Hersteller veröffentlichten Hash vergleichen

# Bootloader-Signaturen überprüfen
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
sigcheck -a C:\Windows\System32\winload.efi
sigcheck -a C:\Windows\System32\ntoskrnl.exe

# Nach unsignierten oder ungültigen Boot-Treibern suchen
sigcheck -u -e C:\Windows\System32\drivers\

# MeasuredBoot-Protokolle auf unerwartete EFI_Boot_Services_Application-Einträge analysieren
# BlackLotus-Komponenten erscheinen als EV_EFI_Boot_Services_Application

# Speicherforensik für Bootphasen-Artefakte
vol3 -f memory.dmp windows.modules
vol3 -f memory.dmp windows.driverscan

Schritt 7: UEFI-Bootkit-Analyseergebnisse dokumentieren

Einen umfassenden Analysebericht erstellen:

Der Bericht sollte Folgendes enthalten:
- Firmware-Version, Hersteller und Plattform-Identifikation
- SPI-Flash-Schutzstatus (Schreibschutz, Sperrbits, Zugriffskontrolle)
- Secure-Boot-Konfiguration und erkannte Bypass-Indikatoren
- UEFI-Variablen-Anomalien (nicht autorisierte Schlüssel, geänderte db/dbx, MOK-Einträge)
- ESP-Inhaltsinventar mit Hash-Überprüfung gegen bekannte korrekte Baselines
- Firmware-Modulvergleich mit Hersteller-Whitelist (hinzugefügt, geändert, entfernt)
- Zuordnung zu bekannter Bootkit-Familie mit Konfidenzniveau
- Ergebnisse der Integritätsprüfung der Boot-Kette für jede Komponente
- Abhilfemaßnahmen (Neuflashen, Schlüsselrotation, Hardwareaustausch)
- MITRE ATT&CK-Zuordnung (T1542.001 - System-Firmware, T1542.003 - Bootkit)

Schlüsselkonzepte

Begriff	Definition
UEFI-Bootkit	Schadsoftware, die in der UEFI-Firmware oder im Bootvorgang persistiert, vor dem Laden des Betriebssystems ausgeführt wird und eine Betriebssystem-Neuinstallation überlebt
SPI-Flash	Serial-Peripheral-Interface-Flash-Speicherchip auf der Hauptplatine, der die UEFI-Firmware speichert; Firmware-Bootkits wie LoJax und MoonBounce ändern SPI-Flash-Inhalte
EFI-Systempartition (ESP)	FAT32-Partition mit EFI-Bootloadern und -Treibern; Bootkits wie BlackLotus und ESPecter ändern Dateien auf der ESP zur Persistenz
Secure Boot	UEFI-Sicherheitsfunktion, die digitale Signaturen von Boot-Komponenten überprüft; kann durch Schwachstellen (CVE-2022-21894) oder MOK-Einträge umgangen werden
DXE-Treiber	Treiber der Driver Execution Environment, die während des UEFI-Boots geladen werden; Firmware-Implantate injizieren bösartige DXE-Treiber, die vor dem Betriebssystem ausgeführt werden
Machine Owner Key (MOK)	Vom Benutzer installierbarer Secure-Boot-Schlüssel; BlackLotus trägt angreifergesteuerte MOKs ein, um bösartige Bootloader zu signieren
chipsec	Intel-Plattform-Sicherheitsbewertungsframework zur Analyse von SPI-Flash, UEFI-Variablen, Secure Boot und Hardware-Sicherheitskonfigurationen
HVCI	Hypervisor-erzwungene Code-Integrität, eine Windows-Sicherheitsfunktion, die Bootkits deaktivieren, um unsignierte Kernel-Treiber zu laden

Werkzeuge und Systeme

• chipsec: Intel-Framework zum Auslesen von SPI-Flash, Lesen von UEFI-Variablen, Überprüfen des Firmware-Schreibschutzes und Auditing der Secure-Boot-Konfiguration
• UEFITool: Open-Source-UEFI-Firmware-Image-Parser zum Inspizieren von Firmware-Volumes, Extrahieren von DXE-Treibern und Vergleichen von Modul-GUIDs
• sigcheck: Sysinternals-Dienstprogramm zum Überprüfen digitaler Signaturen von EFI-Binärdateien und Boot-Ketten-Komponenten
• flashrom: Open-Source-SPI-Flash-Programmierer zum Lesen und Schreiben von Firmware-Chips auf unterstützten Plattformen
• YARA: Mustergesteuerte Analyse-Engine, die mit UEFI-spezifischen Regelsätzen verwendet wird, um bekannte Bootkit-Signaturen in Firmware-Dumps zu erkennen

Häufige Szenarien

Szenario: Untersuchung einer persistenten Kompromittierung, die eine Betriebssystem-Neuinstallation überlebt

Kontext: Ein Unternehmensendpunkt wurde nach einer bestätigten Sicherheitsverletzung neu abgebildet, aber die identische C2-Kommunikation wurde innerhalb von Stunden wieder aufgenommen. Der Endpunkt verfügt über UEFI-Firmware mit aktiviertem Secure Boot und einem TPM 2.0-Chip. Das Sicherheitsteam vermutet ein UEFI-Level-Implantat ähnlich wie BlackLotus oder LoJax.

Vorgehen:

1. System von einem vertrauenswürdigen Linux-Live-USB booten, um keine kompromittierten Betriebssystemkomponenten auszuführen
2. SPI-Flash-Firmware mit chipsec_util.py spi dump für die Offline-Analyse auslesen
3. ESP mounten und alle .efi-Dateien hashen, um sie mit bekannten korrekten Werten von identischer Hardware zu vergleichen
4. Auf das Verzeichnis ESP:/system32/ (BlackLotus-Indikator) und nicht autorisiertes grubx64.efi prüfen
5. Firmware-Module mit UEFIExtract extrahieren und GUID-Inventar mit der Hersteller-Baseline vergleichen
6. Secure-Boot-Variablen überprüfen – nach nicht autorisierten MOK-Einträgen oder geänderten db/dbx suchen
7. SPI-Flash-Schreibschutz und Sperrbits mit chipsec-Modulen prüfen
8. Firmware-Dump und extrahierte Module mit UEFI-spezifischen YARA-Regeln scannen
9. Bei Verdacht auf BlackLotus die Registrierung auf deaktiviertes HVCI und MeasuredBoot-Protokolle auf anomale Einträge prüfen

Fallstricke:

• Ausführung der Analyse vom kompromittierten Betriebssystem aus (Rootkit-Komponenten verstecken sich vor Live-Analysen)
• Nur die ESP überprüfen, ohne den SPI-Flash-Speicher zu untersuchen (übersehen von Firmware-Implantaten wie LoJax, MoonBounce)
• Annahme, dass Secure Boot alle Bootkits verhindert (CVE-2022-21894 und andere Umgehungen existieren)
• Keine Sicherung des ursprünglichen Firmware-Dumps vor der Abhilfe (kritischer forensischer Beweis)
• Firmware neu flashen, ohne zu überprüfen, ob das Hersteller-Image authentisch und unverändert ist

Ausgabeformat

UEFI-BOOTKIT-PERSISTENZ-ANALYSEBERICHT
============================================
System:           Lenovo ThinkPad X1 Carbon Gen 11
Firmware:         N3HET82W (1.54) - Lenovo UEFI BIOS
Plattform:        Intel 13. Gen (Raptor Lake)
TPM:              2.0 (Infineon SLB 9672)
Secure Boot:      AKTIVIERT (UMGANGEN über CVE-2022-21894)
Analysemethode:   Linux-Live-USB + chipsec + UEFITool

SPI-FLASH-SCHUTZSTATUS
BIOS-Schreibschutz:         DEAKTIVIERT [!]
SPI-Flash-Sperre (FLOCKDN): GESETZT [OK]
SMM-BIOS-Schreibschutz:     DEAKTIVIERT [!]
SPI-geschützte Bereiche:    Nur Region 0 (Descriptor)

UEFI-VARIABLEN-ANALYSE
SecureBoot:        Aktiviert (Wert=1)
SetupMode:         Deaktiviert (Wert=0)
PK:                Lenovo Ltd. (legitim)
KEK:               Microsoft + Lenovo (legitim)
db:                MODIFIZIERT – enthält nicht autorisierten Eintrag [!]
  [!] Unbekanntes Zertifikat: CN=Secure Boot Signing, O=Unknown
  [!] Nicht in der Hersteller-Baseline db vorhanden
MOK:               1 nicht autorisierter Schlüssel eingetragen [!]
  [!] MOK eingetragen: CN=shim, selbstsigniert, nicht vom Distributionshersteller

ESP-PARTITIONSANALYSE
EFI-Binärdateien gesamt:     12
Verifiziert (signiert):      9
Modifiziert (Hash-Konflikt): 2 [!]
Nicht autorisiert:           1 [!]

  [!] EFI/Microsoft/Boot/bootmgfw.efi - MODIFIZIERT
      Erwarteter SHA-256: a3f2c8...
      Aktueller SHA-256:  7b1e4d...
      Signatur:           Gültig (signiert mit nicht autorisiertem MOK)

  [!] EFI/Microsoft/Boot/grubx64.efi - NICHT AUTORISIERT
      SHA-256:  e9c1a7...
      Nicht in der Hersteller-Baseline vorhanden
      Entspricht der BlackLotus Stage-2-Lader-Signatur

  [!] system32/-Verzeichnis auf ESP vorhanden (BlackLotus-Artefakt)
      Verzeichnis leer (Dateien nach der Installation gelöscht)

FIRMWARE-MODULANALYSE
Firmware-Module gesamt:       312
Hersteller-Baseline-Module:  312
Hinzugefügte Module:         0
Modifizierte Module:         0
SPI-Flash-Integrität:        SAUBER (kein Firmware-Implantat erkannt)

BOOTKIT-ZUORDNUNG
Familie:           BlackLotus
Konfidenz:         HOCH
Persistenz:        ESP-basiert (nicht SPI-Flash)
Bypass-Methode:    CVE-2022-21894 (baton drop)
MITRE ATT&CK:     T1542.003 (Bootkit), T1553.006 (Code-Signing-Richtlinienänderung)

INDIKATOREN FÜR EINE GEFÄHRDUNG
- ESP:/system32/-Verzeichnis (leer, Artefakt nach Bereinigung)
- ESP:/EFI/Microsoft/Boot/grubx64.efi (nicht autorisiert, BlackLotus-Lader)
- Modifizierte bootmgfw.efi (neu signiert mit Angreifer-MOK)
- HVCI deaktiviert über Registrierung: DeviceGuard\...\Enabled = 0
- Nicht autorisierter MOK-Eintrag im UEFI-Variablen-Speicher
- MeasuredBoot-Protokoll zeigt EV_EFI_Boot_Services_Application für grubx64.efi

ABHILFEMASSNAHMEN
1. bootmgfw.efi durch authentische Kopie von Windows-Installationsmedien ersetzen
2. Nicht autorisierte grubx64.efi und system32/-Verzeichnis von der ESP löschen
3. Secure-Boot-Schlüssel auf Werkseinstellungen zurücksetzen (MOK löschen, PK/KEK/db wiederherstellen)
4. BIOS-Schreibschutz aktivieren und SPI-Flash-Sperrbits überprüfen
5. Firmware-Update auf die neueste Version einspielen (behebt CVE-2022-21894)
6. HVCI aktivieren und über Gruppenrichtlinien überprüfen
7. Nur vertrauenswürdige Zertifikate wieder in die Secure-Boot-db importieren
8. MeasuredBoot-Protokolle auf anomale Boot-Komponenten-Ladevorgänge überwachen