Analyse d'échantillons de bootkit et rootkit
Quand utiliser
- Un système montre des signes de compromission qui persistent après la réinstallation du système d'exploitation
- L'antivirus et l'EDR sont incapables de détecter un malware malgré des preuves claires de compromission
- Le Secure Boot UEFI a été désactivé ou présente des violations d'intégrité
- L'analyse de la mémoire révèle un comportement de rootkit (processus cachés, appels système hookés)
- Enquête sur des menaces de niveau étatique connues pour déployer des bootkits (APT28, APT41, Equation Group)
Ne pas utiliser pour les malwares standard en mode utilisateur ; les bootkits et rootkits opèrent à un niveau fondamentalement différent nécessitant des techniques d'analyse spécialisées.
Prérequis
- Outils d'imagerie disque (dd, FTK Imager) pour acquérir les secteurs MBR/VBR
- UEFITool pour l'analyse du volume du firmware UEFI et l'extraction de modules
- chipsec pour l'évaluation de la sécurité du firmware au niveau matériel
- Ghidra avec support x86 real-mode et 16 bits pour l'analyse du code MBR
- Volatility 3 pour la détection d'artefacts de rootkit au niveau du noyau
- Live USB Linux bootable pour l'analyse hors ligne du système
Flux de travail
Étape 1 : Acquérir les secteurs de démarrage et le firmware
Extraire le MBR, le VBR et le firmware UEFI pour une analyse hors ligne :
# Acquérir le MBR (premiers 512 octets du disque)
dd if=/dev/sda of=mbr.bin bs=512 count=1
# Acquérir la première piste (contient souvent le code du bootkit au-delà du MBR)
dd if=/dev/sda of=first_track.bin bs=512 count=63
# Acquérir le VBR (Volume Boot Record - premier secteur de la partition)
dd if=/dev/sda1 of=vbr.bin bs=512 count=1
# Acquérir la partition système UEFI
mkdir /mnt/efi
mount /dev/sda1 /mnt/efi
cp -r /mnt/efi/EFI /analysis/efi_backup/
# Dumper le firmware UEFI (nécessite chipsec ou flashrom)
# Avec chipsec :
python chipsec_util.py spi dump firmware.rom
# Avec flashrom :
flashrom -p internal -r firmware.rom
# Vérifier l'intégrité du dump du firmware
sha256sum firmware.rom
Étape 2 : Analyser le MBR/VBR pour du code de bootkit
Examiner le code du secteur de démarrage pour des modifications malveillantes :
# Désassembler le code MBR (mode réel 16 bits)
ndisasm -b16 mbr.bin > mbr_disasm.txt
# Comparer le MBR avec le MBR Windows sain connu
# Le MBR Windows standard commence par : EB 5A 90 (JMP 0x5C, NOP)
# MBR Windows 10 standard : 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()
# Vérifier la signature MBR (octets 510-511 doivent être 0x55AA)
if mbr[510:512] == b'\x55\xAA':
print("[*] Signature MBR valide (0x55AA)")
else:
print("[!] Signature MBR invalide")
# Vérifier les signatures de bootkit connues
bootkit_sigs = {
b'\xE8\x00\x00\x5E\x81\xEE': "Bootkit TDL4/Alureon",
b'\xFA\x33\xC0\x8E\xD0\xBC\x00\x7C\x8B\xF4\x50\x07': "MBR Windows standard (sain)",
b'\xEB\x5A\x90\x4E\x54\x46\x53': "VBR NTFS standard (sain)",
}
for sig, name in bootkit_sigs.items():
if sig in mbr:
print(f"[{'!' if 'sain' not in name else '*'}] Correspondance de signature : {name}")
# Vérifier les entrées de la table de partition
print("\nTable de partition :")
for i in range(4):
offset = 446 + (i * 16)
entry = mbr[offset:offset+16]
if entry != b'\x00' * 16:
boot_flag = "Active" if entry[0] == 0x80 else "Inactive"
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} : Type=0x{part_type:02X} {boot_flag} Début=LBA {start_lba} Taille={size_lba} secteurs")
PYEOF
Étape 3 : Analyser le firmware UEFI pour des implants
Inspecter les volumes du firmware UEFI pour des modules non autorisés :
# Extraire les composants du firmware UEFI avec UEFITool
# GUI : Ouvrir firmware.rom -> Inspecter les volumes du firmware
# CLI :
UEFIExtract firmware.rom all
# Lister tous les pilotes DXE (cible la plus courante pour les implants UEFI)
find firmware.rom.dump -name "*.efi" -exec file {} \;
# Comparer avec la liste des modules de firmware sain connu
# Chaque module UEFI a un GUID - comparer avec la base de référence du fournisseur
# Vérifier la configuration Secure Boot
python chipsec_main.py -m common.secureboot.variables
# Vérifier la protection en écriture du SPI flash
python chipsec_main.py -m common.bios_wp
# Vérifier les motifs de malware UEFI connus
yara -r uefi_malware.yar firmware.rom
Points de détection des bootkits UEFI connus :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LoJax (APT28) :
- Flash SPI modifié
- Pilote DXE ajouté qui dépose un agent dans Windows
- Persiste après réinstallation du système d'exploitation et remplacement du disque
BlackLotus :
- Exploite CVE-2022-21894 pour contourner Secure Boot
- Modifie le chargeur de démarrage de la partition système EFI
- Installe un pilote noyau pendant le démarrage
CosmicStrand :
- Modifie le module firmware CORE_DXE
- Hooke l'initialisation du noyau pendant le démarrage
- Dépose du shellcode dans la mémoire du noyau Windows
MoonBounce :
- Implant SPI flash dans le module CORE_DXE
- Fonction GetVariable() modifiée
- Déploie un implant en mode utilisateur via la chaîne de démarrage
ESPecter :
- Modifie le gestionnaire de démarrage Windows sur l'ESP
- Patche winload.efi pour désactiver DSE
- Charge un pilote noyau non signé
Étape 4 : Détecter le comportement de rootkit au niveau du noyau
Analyser le système en cours d'exécution pour des artefacts de rootkit :
# Analyse forensique de la mémoire pour la détection de rootkit
# Détection de hook SSDT
vol3 -f memory.dmp windows.ssdt | grep -v "ntoskrnl\|win32k"
# Processus cachés (DKOM)
vol3 -f memory.dmp windows.psscan > psscan.txt
vol3 -f memory.dmp windows.pslist > pslist.txt
# Diff pour trouver les processus cachés
# Enregistrement de callbacks du noyau (les rootkits enregistrent des callbacks pour le filtrage)
vol3 -f memory.dmp windows.callbacks
# Analyse des pilotes
vol3 -f memory.dmp windows.driverscan
vol3 -f memory.dmp windows.modules
# Vérifier les pilotes non signés
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 "Non signé"
fi
done
# Détection de hook IDT
vol3 -f memory.dmp windows.idt
Étape 5 : Vérification de l'intégrité de la chaîne de démarrage
Vérifier l'intégrité de toute la chaîne de démarrage :
# Vérifier la signature du gestionnaire de démarrage Windows
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
# Vérifier winload.efi
sigcheck -a C:\Windows\System32\winload.efi
# Vérifier ntoskrnl.exe
sigcheck -a C:\Windows\System32\ntoskrnl.exe
# Vérifier les logs de démarrage mesuré (si TPM disponible)
# Windows : BCDEdit /enum firmware
bcdedit /enum firmware
# Vérifier l'état de Secure Boot
Confirm-SecureBootUEFI # Applet de commande PowerShell
# Vérifier la configuration de démarrage pour des altérations
bcdedit /v
# Rechercher des modifications de la configuration de démarrage
# testsigning : doit être Non
# nointegritychecks : doit être Non
# debug : doit être Non
bcdedit | findstr /i "testsigning nointegritychecks debug"
Étape 6 : Documenter l'analyse du bootkit/rootkit
Compiler des résultats d'analyse complets :
L'analyse doit documenter :
- Statut d'intégrité du secteur de démarrage (MBR/VBR) avec comparaison hexadécimale
- Inventaire des modules du firmware UEFI et vérification d'intégrité
- Statut de Secure Boot et tout mécanisme de contournement détecté
- Hooks au niveau du noyau (SSDT, IDT, IRP, inline) identifiés
- Processus, pilotes et fichiers cachés découverts
- Mécanisme de persistance (flash SPI, ESP, MBR, pilote noyau)
- Résultats de la vérification d'intégrité de la chaîne de démarrage
- Attribution aux familles de bootkits connues si possible
- Étapes de correction (reflash du firmware, reconstruction du MBR, remplacement du matériel)
Concepts clés
| Terme | Définition |
|---|---|
| Bootkit | Malware qui infecte le processus de démarrage (MBR, VBR, UEFI) pour s'exécuter avant le chargement du système d'exploitation, obtenant un contrôle persistant de bas niveau |
| MBR (Master Boot Record) | 512 premiers octets d'un disque contenant le code d'amorçage et la table de partition ; les bootkits MBR remplacent ce code par des chargeurs malveillants |
| UEFI (Unified Extensible Firmware Interface) | Interface firmware moderne remplaçant le BIOS ; les bootkits UEFI implantent des modules malveillants dans les volumes du firmware ou modifient l'ESP |
| Secure Boot | Fonctionnalité de sécurité UEFI vérifiant les signatures numériques des composants de démarrage ; des bootkits comme BlackLotus exploitent des vulnérabilités pour le contourner |
| Flash SPI | Puce mémoire flash stockant le firmware UEFI ; des bootkits avancés comme LoJax et MoonBounce modifient le flash SPI pour une persistance au niveau du firmware |
| DKOM (Direct Kernel Object Manipulation) | Technique de rootkit modifiant les structures du noyau pour cacher des processus, fichiers et connexions réseau sans hooker de fonctions |
| Driver Signature Enforcement (DSE) | Fonctionnalité de sécurité Windows exigeant que les pilotes noyau soient signés numériquement ; les bootkits désactivent DSE pendant le démarrage pour charger des pilotes rootkit non signés |
Outils et systèmes
- UEFITool : Éditeur et analyseur open-source d'images firmware UEFI pour inspecter les volumes, pilotes et modules du firmware
- chipsec : Framework d'évaluation de la sécurité matérielle Intel pour vérifier la protection du flash SPI, Secure Boot et la configuration UEFI
- Volatility : Framework d'analyse forensique de la mémoire avec des plugins d'analyse SSDT, IDT, callback et pilotes pour la détection de rootkit au niveau du noyau
- GMER : Outil de détection de rootkit Windows recherchant les hooks SSDT, IDT, les processus cachés et les modules noyau modifiés
- Analyseur de bootkits : Outil spécialisé pour analyser le code MBR/VBR, y compris le désassemblage et la comparaison avec des bases de référence saines connues
Scénarios courants
Scénario : Enquête sur une compromission persistante survivant à la réinstallation du système d'exploitation
Contexte : Une organisation a réinstallé l'image d'un poste de travail compromis, mais le même C2 beaconing a repris en quelques heures. L'analyse forensique standard du disque ne trouve aucun malware. Un bootkit UEFI est suspecté.
Approche :
- Booter à partir d'un live USB Linux pour éviter d'exécuter tout composant du système d'exploitation compromis
- Dumper le firmware SPI flash à l'aide de chipsec ou flashrom pour une analyse hors ligne
- Dumper les secteurs MBR et VBR avec dd pour l'analyse du secteur de démarrage
- Copier la partition système EFI pour la vérification d'intégrité du chargeur de démarrage
- Ouvrir le dump SPI dans UEFITool et comparer les GUID des modules avec le firmware fourni par le fournisseur
- Rechercher des pilotes DXE supplémentaires ou modifiés qui ne devraient pas être présents
- Analyser les modules suspects avec Ghidra (format de module UEFI x86_64)
- Vérifier la configuration Secure Boot et rechercher des contournements basés sur des exploits
Pièges :
- Analyser le système alors que le système d'exploitation compromis est en cours d'exécution (le rootkit peut se cacher de l'analyse en direct)
- Ne pas vérifier le flash SPI (analyser uniquement les composants de démarrage sur disque omet les implants au niveau du firmware)
- Supposer que Secure Boot empêche tous les bootkits (des contournements connus existent, par exemple CVE-2022-21894)
- Ne pas conserver le dump firmware original avant de reflasher (preuve critique pour l'attribution)
Format de sortie
RAPPORT D'ANALYSE DE BOOTKIT / ROOTKIT
=========================================
Système : Dell OptiPlex 7090 (UEFI, TPM 2.0)
Version firmware : 1.15.0 (Dell)
Secure Boot : ACTIVÉ (mais contourné)
Méthode de capture : Live USB Linux + dump SPI chipsec
ANALYSE MBR/VBR
Signature MBR : Valide (0x55AA)
Code MBR : CORRESPOND au MBR Windows 10 standard (sain)
Code VBR : CORRESPOND au VBR NTFS standard (sain)
ANALYSE DU FIRMWARE UEFI
Modules totaux : 287
Attendu fournisseur : 285
Modules supplémentaires : 2 NON AUTORISÉS
[!] Pilote DXE GUID : {ABCD1234-...} "SmmAccessDxe_mod" (MODIFIÉ)
Taille originale : 12 288 octets
Taille actuelle : 45 056 octets (32 Ko AJOUTÉS)
Entropie : 7,82 (ÉLEVÉE - charge utile chiffrée)
[!] Pilote DXE GUID : {EFGH5678-...} "UefiPayloadDxe" (NOUVEAU - pas dans le firmware fournisseur)
Taille : 28 672 octets
Fonction : Dépose un agent de persistance pendant le démarrage
INTÉGRITÉ DE LA CHAÎNE DE DÉMARRAGE
bootmgfw.efi : MODIFIÉ (hash non correspondant, contournement Secure Boot via CVE-2022-21894)
winload.efi : MODIFIÉ (DSE désactivé au moment du chargement)
ntoskrnl.exe : SAIN (mais pilote non signé chargé après le démarrage)
COMPOSANTS DU ROOTKIT AU NIVEAU DU NOYAU
Pilote : C:\Windows\System32\drivers\null_mod.sys (non signé, caché)
Hooks SSDT : 3 (NtQuerySystemInformation, NtQueryDirectoryFile, NtDeviceIoControlFile)
Processus cachés : 2 (PID 6784 : beacon.exe, PID 6812 : keylog.exe)
Fichiers cachés : C:\Windows\System32\drivers\null_mod.sys
ATTRIBUTION
Famille : Variante de BlackLotus
Confiance : ÉLEVÉE (exploit CVE-2022-21894, motif de modification ESP correspondant)
CORRECTION
1. Reflasher le firmware SPI avec l'image fournisseur saine via un programmateur matériel
2. Reconstruire la partition système EFI à partir d'un support d'installation Windows sain
3. Réinstaller le système d'exploitation à partir d'un support vérifié
4. Activer toutes les protections en écriture du firmware
5. Mettre à jour le firmware vers la dernière version (corrige CVE-2022-21894)