Analyse von Bootkit- und Rootkit-Proben
Wann verwenden
- Ein System zeigt Anzeichen einer Kompromittierung, die eine Neuinstallation des Betriebssystems überlebt
- Antivirus und EDR können Malware trotz klarer Hinweise auf eine Kompromittierung nicht erkennen
- UEFI Secure Boot wurde deaktiviert oder zeigt Integritätsverletzungen
- Memory Forensik zeigt Rootkit-Verhalten (versteckte Prozesse, gehackte Systemaufrufe)
- Untersuchung von Bedrohungen auf staatlicher Ebene, die bekanntermaßen Bootkits einsetzen (APT28, APT41, Equation Group)
Nicht verwenden für Standard-Benutzermodus-Malware; Bootkits und Rootkits arbeiten auf einer grundlegend anderen Ebene und erfordern spezielle Analysetechniken.
Voraussetzungen
- Datenträger-Imaging-Tools (dd, FTK Imager) zum Erfassen von MBR/VBR-Sektoren
- UEFITool für die Analyse von UEFI-Firmware-Volumes und Modulextraktion
- chipsec für die hardwarenahe Firmware-Sicherheitsbewertung
- Ghidra mit x86 Real-Mode und 16-Bit-Unterstützung für MBR-Codeanalyse
- Volatility 3 zur Erkennung von Kernel-Rootkit-Artefakten
- Bootfähiger Linux-Live-USB für die Offline-Systemanalyse
Arbeitsablauf
Schritt 1: Boot-Sektoren und Firmware erfassen
Extrahieren Sie MBR, VBR und UEFI-Firmware für die Offline-Analyse:
# MBR erfassen (erste 512 Bytes der Festplatte)
dd if=/dev/sda of=mbr.bin bs=512 count=1
# Erste Spur erfassen (enthält oft Bootkit-Code jenseits des MBR)
dd if=/dev/sda of=first_track.bin bs=512 count=63
# VBR erfassen (Volume Boot Record - erster Sektor der Partition)
dd if=/dev/sda1 of=vbr.bin bs=512 count=1
# UEFI-Systempartition erfassen
mkdir /mnt/efi
mount /dev/sda1 /mnt/efi
cp -r /mnt/efi/EFI /analysis/efi_backup/
# UEFI-Firmware dumpen (erfordert chipsec oder flashrom)
# Mit chipsec:
python chipsec_util.py spi dump firmware.rom
# Mit flashrom:
flashrom -p internal -r firmware.rom
# Integrität des Firmware-Dumps prüfen
sha256sum firmware.rom
Schritt 2: MBR/VBR auf Bootkit-Code analysieren
Bootsektorcode auf bösartige Modifikationen untersuchen:
# MBR-Code disassemblieren (16-Bit Real Mode)
ndisasm -b16 mbr.bin > mbr_disasm.txt
# MBR mit bekanntem intaktem Windows-MBR vergleichen
# Standard-Windows-MBR beginnt mit: EB 5A 90 (JMP 0x5C, NOP)
# Standard Windows 10 MBR: 33 C0 8E D0 BC 00 7C (XOR AX,AX; MOV SS,AX; MOV SP,7C00h)
python3 << 'PYEOF'
with open("mbr.bin", "rb") as f:
mbr = f.read()
# MBR-Signatur prüfen (Bytes 510-511 sollten 0x55AA sein)
if mbr[510:512] == b'\x55\xAA':
print("[*] Gültige MBR-Signatur (0x55AA)")
else:
print("[!] Ungültige MBR-Signatur")
# Nach bekannten Bootkit-Signaturen suchen
bootkit_sigs = {
b'\xE8\x00\x00\x5E\x81\xEE': "TDL4/Alureon Bootkit",
b'\xFA\x33\xC0\x8E\xD0\xBC\x00\x7C\x8B\xF4\x50\x07': "Standard Windows MBR (sauber)",
b'\xEB\x5A\x90\x4E\x54\x46\x53': "Standard NTFS VBR (sauber)",
}
for sig, name in bootkit_sigs.items():
if sig in mbr:
print(f"[{'!' if 'sauber' not in name else '*'}] Signatur-Übereinstimmung: {name}")
# Partitionstabelleneinträge prüfen
print("\nPartitionstabelle:")
for i in range(4):
offset = 446 + (i * 16)
entry = mbr[offset:offset+16]
if entry != b'\x00' * 16:
boot_flag = "Aktiv" if entry[0] == 0x80 else "Inaktiv"
part_type = entry[4]
start_lba = int.from_bytes(entry[8:12], 'little')
size_lba = int.from_bytes(entry[12:16], 'little')
print(f" Partition {i+1}: Typ=0x{part_type:02X} {boot_flag} Start=LBA {start_lba} Größe={size_lba} Sektoren")
PYEOF
Schritt 3: UEFI-Firmware auf Implantate untersuchen
UEFI-Firmware-Volumes auf nicht autorisierte Module prüfen:
# UEFI-Firmware-Komponenten mit UEFITool extrahieren
# GUI: Öffnen Sie firmware.rom -> Firmware-Volumes inspizieren
# CLI:
UEFIExtract firmware.rom all
# Alle DXE-Treiber auflisten (häufigstes Ziel für UEFI-Implantate)
find firmware.rom.dump -name "*.efi" -exec file {} \;
# Mit Liste bekannter intakter Firmware-Module vergleichen
# Jedes UEFI-Modul hat eine GUID - mit dem Baseline des Herstellers vergleichen
# Secure Boot Konfiguration prüfen
python chipsec_main.py -m common.secureboot.variables
# SPI-Flash-Schreibschutz prüfen
python chipsec_main.py -m common.bios_wp
# Nach bekannten UEFI-Malware-Mustern suchen
yara -r uefi_malware.yar firmware.rom
Bekannte UEFI-Bootkit-Erkennungspunkte:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LoJax (APT28):
- Modifizierter SPI-Flash
- Hinzugefügter DXE-Treiber, der einen Agenten zu Windows ablegt
- Überlebt Betriebssystem-Neuinstallation und Datenträgeraustausch
BlackLotus:
- Nutzt CVE-2022-21894 aus, um Secure Boot zu umgehen
- Modifiziert den EFI-Systempartitions-Bootloader
- Installiert Kernel-Treiber während des Bootvorgangs
CosmicStrand:
- Modifiziert das CORE_DXE Firmware-Modul
- Hookt die Kernel-Initialisierung während des Bootvorgangs
- Legt Shellcode in den Windows-Kernel-Speicher ab
MoonBounce:
- SPI-Flash-Implantat im CORE_DXE-Modul
- Modifizierte GetVariable()-Funktion
- Setzt Benutzermodus-Implantat über die Bootkette ab
ESPecter:
- Modifiziert den Windows Boot Manager auf der ESP
- Patched winload.efi, um DSE zu deaktivieren
- Lädt nicht signierte Kernel-Treiber
Schritt 4: Kernel-Level-Rootkit-Verhalten erkennen
Das laufende System auf Rootkit-Artefakte analysieren:
# Memory Forensik zur Rootkit-Erkennung
# SSDT-Hook-Erkennung
vol3 -f memory.dmp windows.ssdt | grep -v "ntoskrnl\|win32k"
# Versteckte Prozesse (DKOM)
vol3 -f memory.dmp windows.psscan > psscan.txt
vol3 -f memory.dmp windows.pslist > pslist.txt
# Diff, um versteckte Prozesse zu finden
# Kernel-Callback-Registrierung (Rootkits registrieren Callbacks zur Filterung)
vol3 -f memory.dmp windows.callbacks
# Treiberanalyse
vol3 -f memory.dmp windows.driverscan
vol3 -f memory.dmp windows.modules
# Nach nicht signierten Treibern suchen
vol3 -f memory.dmp windows.driverscan | while read line; do
driver_path=$(echo "$line" | awk '{print $NF}')
if [ -f "$driver_path" ]; then
sigcheck -nobanner "$driver_path" 2>/dev/null | grep "Unsigned"
fi
done
# IDT-Hook-Erkennung
vol3 -f memory.dmp windows.idt
Schritt 5: Integritätsprüfung der Bootkette
Die Integrität der gesamten Bootkette prüfen:
# Windows Boot Manager Signatur prüfen
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
# winload.efi prüfen
sigcheck -a C:\Windows\System32\winload.efi
# ntoskrnl.exe prüfen
sigcheck -a C:\Windows\System32\ntoskrnl.exe
# Measured Boot-Protokolle prüfen (falls TPM verfügbar)
# Windows: BCDEdit /enum firmware
bcdedit /enum firmware
# Secure Boot Status prüfen
Confirm-SecureBootUEFI # PowerShell-Cmdlet
# Boot-Konfiguration auf Manipulation prüfen
bcdedit /v
# Nach Boot-Konfigurationsänderungen suchen
# testsigning: sollte Nein sein
# nointegritychecks: sollte Nein sein
# debug: sollte Nein sein
bcdedit | findstr /i "testsigning nointegritychecks debug"
Schritt 6: Bootkit-/Rootkit-Analyse dokumentieren
Stellen Sie umfassende Analyseergebnisse zusammen:
Die Analyse sollte Folgendes dokumentieren:
- Bootsektor-(MBR/VBR)-Integritätsstatus mit Hex-Vergleich
- Bestandsaufnahme der UEFI-Firmware-Module und Integritätsprüfung
- Secure Boot-Status und alle erkannten Umgehungsmechanismen
- Identifizierte Kernel-Level-Hooks (SSDT, IDT, IRP, Inline)
- Entdeckte versteckte Prozesse, Treiber und Dateien
- Persistenzmechanismus (SPI-Flash, ESP, MBR, Kernel-Treiber)
- Ergebnisse der Bootketten-Integritätsprüfung
- Attribution zu bekannten Bootkit-Familien, falls möglich
- Schritte zur Behebung (Firmware neu flashen, MBR neu aufbauen, Hardware ersetzen)
Schlüsselkonzepte
| Begriff | Definition |
|---|---|
| Bootkit | Malware, die den Bootvorgang infiziert (MBR, VBR, UEFI), um vor dem Laden des Betriebssystems ausgeführt zu werden und dauerhafte Low-Level-Kontrolle zu erlangen |
| MBR (Master Boot Record) | Erste 512 Bytes einer Festplatte, die Bootstrap-Code und Partitionstabelle enthalten; MBR-Bootkits ersetzen diesen Code durch bösartige Lader |
| UEFI (Unified Extensible Firmware Interface) | Moderne Firmware-Schnittstelle, die BIOS ersetzt; UEFI-Bootkits implantieren bösartige Module in Firmware-Volumes oder modifizieren die ESP |
| Secure Boot | UEFI-Sicherheitsfunktion, die digitale Signaturen von Boot-Komponenten prüft; Bootkits wie BlackLotus nutzen Sicherheitslücken aus, um sie zu umgehen |
| SPI Flash | Flash-Speicherchip, der die UEFI-Firmware speichert; fortgeschrittene Bootkits wie LoJax und MoonBounce modifizieren den SPI-Flash für Persistenz auf Firmware-Ebene |
| DKOM (Direct Kernel Object Manipulation) | Rootkit-Technik, die Kernel-Strukturen modifiziert, um Prozesse, Dateien und Netzwerkverbindungen zu verstecken, ohne Funktionen zu hooken |
| Driver Signature Enforcement (DSE) | Windows-Sicherheitsfunktion, die digitale Signaturen für Kernel-Treiber erfordert; Bootkits deaktivieren DSE während des Bootvorgangs, um nicht signierte Rootkit-Treiber zu laden |
Tools & Systeme
- UEFITool: Open-Source-UEFI-Firmware-Bildeditor und -Parser zur Inspektion von Firmware-Volumes, Treibern und Modulen
- chipsec: Intel Hardware-Sicherheitsbewertungs-Framework zur Überprüfung des SPI-Flash-Schutzes, von Secure Boot und der UEFI-Konfiguration
- Volatility: Memory-Forensik-Framework mit SSDT-, IDT-, Callback- und Treiberanalyse-Plugins zur Kernel-Rootkit-Erkennung
- GMER: Windows-Rootkit-Erkennungstool, das nach SSDT-Hooks, IDT-Hooks, versteckten Prozessen und modifizierten Kernel-Modulen sucht
- Bootkits Analyzer: Spezielles Tool zur Analyse von MBR/VBR-Code, inklusive Disassemblierung und Vergleich mit bekannten intakten Baselines
Häufige Szenarien
Szenario: Untersuchung einer persistenten Kompromittierung, die eine Betriebssystem-Neuinstallation überlebt
Kontext: Eine Organisation hat eine kompromittierte Workstation neu abgebildet, aber das gleiche C2-Beaconing wurde innerhalb von Stunden wieder aufgenommen. Die Standard-Datenträgerforensik findet keine Malware. Ein UEFI-Bootkit wird vermutet.
Ansatz:
- Booten Sie von einem Linux-Live-USB, um die Ausführung kompromittierter Betriebssystemkomponenten zu vermeiden
- Dumpen Sie die SPI-Flash-Firmware mit chipsec oder flashrom für die Offline-Analyse
- Dumpen Sie die MBR- und VBR-Sektoren mit dd für die Bootsektoranalyse
- Kopieren Sie die EFI-Systempartition zur Überprüfung der Bootloader-Integrität
- Öffnen Sie den SPI-Dump in UEFITool und vergleichen Sie die Modul-GUIDs mit der vom Hersteller bereitgestellten Firmware
- Achten Sie auf zusätzliche oder modifizierte DXE-Treiber, die nicht vorhanden sein sollten
- Analysieren Sie verdächtige Module mit Ghidra (x86_64 UEFI-Modulformat)
- Überprüfen Sie die Secure Boot-Konfiguration und suchen Sie nach ausnutzungsbasierten Umgehungen
Fallstricke:
- Analyse des Systems, während das kompromittierte Betriebssystem läuft (Rootkit kann sich vor der Live-Analyse verstecken)
- Nichtüberprüfung des SPI-Flashs (nur Analyse von datenträgerbasierten Boot-Komponenten übersieht Implantate auf Firmware-Ebene)
- Annahme, dass Secure Boot alle Bootkits verhindert (bekannte Umgehungen existieren, z. B. CVE-2022-21894)
- Nichtaufbewahren des originalen Firmware-Dumps vor dem Neuflashen (entscheidender Beweis für die Attribution)
Ausgabeformat
BOOTKIT / ROOTKIT ANALYSEBERICHT
====================================
System: Dell OptiPlex 7090 (UEFI, TPM 2.0)
Firmware-Version: 1.15.0 (Dell)
Secure Boot: AKTIVIERT (aber umgangen)
Erfassungsmethode: Linux Live USB + chipsec SPI Dump
MBR/VBR-ANALYSE
MBR-Signatur: Gültig (0x55AA)
MBR-Code: STIMMT MIT Standard Windows 10 MBR überein (sauber)
VBR-Code: STIMMT MIT Standard NTFS VBR überein (sauber)
UEFI-FIRMWARE-ANALYSE
Module gesamt: 287
Vom Hersteller erwartet: 285
Zusätzliche Module: 2 NICHT AUTORISIERT
[!] DXE-Treiber GUID: {ABCD1234-...} "SmmAccessDxe_mod" (MODIFIZIERT)
Originalgröße: 12.288 Bytes
Aktuelle Größe: 45.056 Bytes (32 KB HINZUGEFÜGT)
Entropie: 7,82 (HOCH - verschlüsselte Nutzlast)
[!] DXE-Treiber GUID: {EFGH5678-...} "UefiPayloadDxe" (NEU - nicht in Hersteller-Firmware)
Größe: 28.672 Bytes
Funktion: Setzt während des Bootvorgangs ein Persistenz-Agent ab
BOOTKETTEN-INTEGRITÄT
bootmgfw.efi: MODIFIZIERT (Hash-Konflikt, Secure Boot-Umgehung via CVE-2022-21894)
winload.efi: MODIFIZIERT (DSE beim Laden deaktiviert)
ntoskrnl.exe: SAUBER (aber nicht signierter Treiber nach dem Booten geladen)
KERNEL-ROOTKIT-KOMPONENTEN
Treiber: C:\Windows\System32\drivers\null_mod.sys (nicht signiert, versteckt)
SSDT-Hooks: 3 (NtQuerySystemInformation, NtQueryDirectoryFile, NtDeviceIoControlFile)
Versteckte Prozesse: 2 (PID 6784: beacon.exe, PID 6812: keylog.exe)
Versteckte Dateien: C:\Windows\System32\drivers\null_mod.sys
ATTRIBUTION
Familie: BlackLotus-Variante
Vertrauen: HOCH (CVE-2022-21894-Ausnutzung, ESP-Modifikationsmuster stimmt überein)
BEHEBUNG
1. SPI-Firmware mit sauberem Hersteller-Image über Hardware-Programmierer neu flashen
2. EFI-Systempartition von sauberen Windows-Installationsmedien neu aufbauen
3. Betriebssystem von verifizierten Medien neu installieren
4. Alle Firmware-Schreibschutzfunktionen aktivieren
5. Firmware auf die neueste Version aktualisieren (patched CVE-2022-21894)