Analyse de la persistance des bootkits UEFI
Quand l'utiliser
- Un système compromis rétablit une communication C2 après une réinstallation du système d'exploitation ou un remplacement du disque.
- Secure Boot a été falsifié, désactivé ou montre un enrôlement inattendu de Machine Owner Key (MOK).
- La vérification d'intégrité du firmware échoue par rapport aux bases de référence fournies par le fournisseur.
- L'analyse de la mémoire révèle des composants de rootkit se chargeant pendant la phase de démarrage précoce.
- Enquête sur des campagnes de menaces persistantes avancées (APT) connues pour déployer des implants UEFI.
- Audit de la posture de sécurité du firmware pour le renforcement des points de terminaison en entreprise.
Ne pas utiliser pour les bootkits MBR standard sur les systèmes BIOS hérités sans UEFI ; utiliser l'analyse de bootkit MBR/VBR à la place.
Prérequis
- Framework chipsec pour le dump de la mémoire flash SPI, l'inspection des variables UEFI et les modules de sécurité du firmware.
- UEFITool / UEFIExtract pour l'analyse des volumes de firmware et l'extraction des pilotes DXE.
- Python 3.8+ avec les modules struct, hashlib, subprocess et os.
- Clé USB Linux bootable pour l'analyse hors ligne (éviter d'exécuter le système d'exploitation compromis).
- Volatility 3 pour l'analyse de la mémoire des artefacts de la phase de démarrage.
- YARA avec des ensembles de règles pour les malwares UEFI pour la détection basée sur des motifs.
- Accès aux bases de référence du firmware du fournisseur pour la comparaison d'intégrité.
Flux de travail
Étape 1 : Dumper le firmware SPI Flash
Acquérir le firmware UEFI à partir de la puce SPI flash pour une analyse hors ligne :
# Utilisation de chipsec pour dumper le contenu de la SPI flash
python chipsec_util.py spi dump firmware_dump.rom
# Utilisation de flashrom comme alternative
flashrom -p internal -r firmware_dump.rom
# Vérifier l'intégrité du dump
sha256sum firmware_dump.rom
# Lire les informations du descripteur SPI flash
python chipsec_util.py spi info
# Vérifier les permissions d'accès à la région SPI flash
python chipsec_main.py -m common.spi_access
# Vérifier que la protection en écriture du BIOS est activée
python chipsec_main.py -m common.bios_wp
# Vérifier le verrouillage du contrôleur SPI flash
python chipsec_main.py -m common.spi_lock
Étape 2 : Inspecter les variables UEFI
Énumérer et analyser les variables UEFI pour détecter des modifications non autorisées :
# Lister toutes les variables UEFI sur un système en direct
python chipsec_util.py uefi var-list
# Lister les variables UEFI à partir d'un dump de la SPI flash
python chipsec_util.py uefi var-list-spi firmware_dump.rom
# Lire des variables Secure Boot spécifiques
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
# Dumper les bases de données de clés UEFI pour analyse
python chipsec_util.py uefi keys
# Vérifier la configuration du module Secure Boot
python chipsec_main.py -m common.secureboot.variables
Étape 3 : Analyser la partition système EFI (ESP)
Inspecter l'ESP pour détecter des composants de démarrage non autorisés ou modifiés :
# Monter l'ESP (généralement la première partition FAT32, ~100-500 Mo)
mkdir /mnt/esp
mount /dev/sda1 /mnt/esp
# Lister tous les fichiers sur l'ESP avec les horodatages
find /mnt/esp -type f -exec ls -la {} \;
# Vérifier la présence d'indicateurs BlackLotus - répertoire personnalisé sous ESP:/system32/
ls -la /mnt/esp/system32/ 2>/dev/null
# Vérifier la signature du gestionnaire de démarrage Windows
sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi
# Hacher tous les binaires EFI pour comparaison avec des valeurs connues
find /mnt/esp -name "*.efi" -exec sha256sum {} \;
# Vérifier la présence de fichiers .efi non autorisés en dehors des répertoires standard
find /mnt/esp -name "*.efi" | grep -v "Microsoft\|Boot\|ubuntu\|grub"
# Rechercher grubx64.efi déposé par BlackLotus
find /mnt/esp -name "grubx64.efi" -exec sha256sum {} \;
# Examiner les journaux MeasuredBoot pour détecter des anomalies (Windows)
# Les journaux se trouvent dans C:\Windows\Logs\MeasuredBoot\
Étape 4 : Scanner le firmware pour les signatures de bootkits connus
Analyser le dump du firmware pour détecter des motifs de malwares UEFI connus :
# Extraire tous les modules du firmware avec UEFIExtract
UEFIExtract firmware_dump.rom all
# Générer une liste blanche des modules du firmware à partir de la référence du fournisseur
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom
# Comparer le firmware actuel avec la liste blanche
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom
# Scanner le firmware avec des règles YARA spécifiques à l'UEFI
yara -r uefi_bootkits.yar firmware_dump.rom
# Scanner les modules extraits individuellement
find firmware_dump.rom.dump -name "*.efi" -exec yara -r uefi_bootkits.yar {} \;
# Vérifier la présence du module CORE_DXE modifié (ciblé par MoonBounce, CosmicStrand)
# Comparer le GUID et le hachage avec la référence du fournisseur
Étape 5 : Détecter les mécanismes de contournement de Secure Boot
Vérifier les techniques connues de contournement de Secure Boot :
# Vérifier si Secure Boot est activé
python chipsec_main.py -m common.secureboot.variables
# Vérifier les protections SMM (System Management Mode)
python chipsec_main.py -m common.smm
# Vérifier la protection en écriture du BIOS SMM
python chipsec_main.py -m common.bios_smi
# Sous Windows - vérifier la configuration de démarrage pour les indicateurs de contournement
bcdedit /enum firmware
bcdedit /v
# Vérifier la présence des indicateurs testsigning/nointegritychecks/debug
bcdedit | findstr /i "testsigning nointegritychecks debug"
# Vérifier que HVCI (Hypervisor-enforced Code Integrity) n'est pas désactivé
# BlackLotus définit HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled
# Vérifier l'état de Secure Boot via PowerShell
# Confirm-SecureBootUEFI retourne True s'il est correctement activé
Étape 6 : Effectuer une vérification d'intégrité de la chaîne de démarrage
Vérifier chaque composant de la chaîne de démarrage, du firmware au noyau :
# Vérifier l'intégrité du firmware par rapport au hachage du fournisseur
sha256sum firmware_dump.rom
# Comparer avec le hachage publié par le fournisseur
# Vérifier les signatures des chargeurs de démarrage
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
sigcheck -a C:\Windows\System32\winload.efi
sigcheck -a C:\Windows\System32\ntoskrnl.exe
# Vérifier la présence de pilotes de démarrage non signés ou invalides
sigcheck -u -e C:\Windows\System32\drivers\
# Analyser les journaux MeasuredBoot pour des entrées EFI_Boot_Services_Application inattendues
# Les composants BlackLotus apparaissent comme EV_EFI_Boot_Services_Application
# Analyse de la mémoire pour les artefacts de la phase de démarrage
vol3 -f memory.dmp windows.modules
vol3 -f memory.dmp windows.driverscan
Étape 7 : Documenter les résultats de l'analyse du bootkit UEFI
Compiler un rapport d'analyse complet :
Le rapport doit inclure :
- Version du firmware, fournisseur et identification de la plateforme
- État de la protection SPI flash (protection en écriture, bits de verrouillage, contrôle d'accès)
- Configuration de Secure Boot et tout indicateur de contournement détecté
- Anomalies des variables UEFI (clés non autorisées, db/dbx modifié, enrôlement MOK)
- Inventaire du contenu de l'ESP avec vérification des hachages par rapport aux bases de référence
- Comparaison des modules du firmware avec la liste blanche du fournisseur (ajoutés, modifiés, supprimés)
- Attribution à une famille de bootkits connue avec niveau de confiance
- Résultats de la vérification d'intégrité de la chaîne de démarrage pour chaque composant
- Étapes de remédiation (reflash, rotation des clés, remplacement du matériel)
- Correspondance MITRE ATT&CK (T1542.001 – Firmware système, T1542.003 – Bootkit)
Concepts clés
| Terme | Définition |
|---|---|
| Bootkit UEFI | Logiciel malveillant persistant dans le firmware UEFI ou le processus de démarrage, s'exécutant avant le chargement du système d'exploitation et survivant à la réinstallation du système. |
| SPI Flash | Puce de mémoire flash à interface périphérique série située sur la carte mère et stockant le firmware UEFI ; les bootkits au niveau du firmware comme LoJax et MoonBounce modifient le contenu de la SPI flash. |
| Partition système EFI (ESP) | Partition FAT32 contenant les chargeurs et pilotes EFI ; les bootkits comme BlackLotus et ESPecter modifient les fichiers sur l'ESP pour assurer la persistance. |
| Secure Boot | Fonction de sécurité UEFI qui vérifie les signatures numériques des composants de démarrage ; peut être contournée via des vulnérabilités (CVE-2022-21894) ou un enrôlement MOK. |
| Pilote DXE | Pilote de l'environnement d'exécution des pilotes chargé pendant le démarrage UEFI ; les implants du firmware injectent des pilotes DXE malveillants qui s'exécutent avant le système d'exploitation. |
| Machine Owner Key (MOK) | Clé Secure Boot installable par l'utilisateur ; BlackLotus enrôle des MOK contrôlés par l'attaquant pour signer des chargeurs de démarrage malveillants. |
| chipsec | Framework d'évaluation de la sécurité des plateformes Intel pour l'analyse de la SPI flash, des variables UEFI, de Secure Boot et des configurations de sécurité matérielles. |
| HVCI | Hypervisor-enforced Code Integrity, une fonction de sécurité Windows que les bootkits désactivent pour charger des pilotes noyau non signés. |
Outils et systèmes
- chipsec : Framework Intel pour dumper la SPI flash, lire les variables UEFI, vérifier la protection en écriture du firmware et auditer la configuration de Secure Boot.
- UEFITool : Analyseur d'images de firmware UEFI open source pour inspecter les volumes de firmware, extraire les pilotes DXE et comparer les GUID des modules.
- sigcheck : Utilitaire Sysinternals pour vérifier les signatures numériques des binaires EFI et des composants de la chaîne de démarrage.
- flashrom : Programmeur SPI flash open source pour lire et écrire des puces de firmware sur les plateformes prises en charge.
- YARA : Moteur de correspondance de motifs utilisé avec des ensembles de règles spécifiques à l'UEFI pour détecter les signatures de bootkits connues dans les dumps de firmware.
Scénarios courants
Scénario : Enquête sur une compromission persistante survivant à la réinstallation du système d'exploitation
Contexte : Un point de terminaison d'entreprise a été réinstallé après une violation confirmée, mais une communication C2 identique a repris en quelques heures. Le point de terminaison dispose d'un firmware UEFI avec Secure Boot activé et d'une puce TPM 2.0. L'équipe de sécurité soupçonne un implant de niveau UEFI similaire à BlackLotus ou LoJax.
Approche :
- Démarrer le système à partir d'une clé USB Linux de confiance pour éviter d'exécuter tout composant du système d'exploitation compromis.
- Dumper le firmware SPI flash à l'aide de
chipsec_util.py spi dumppour une analyse hors ligne. - Monter l'ESP et hacher tous les fichiers
.efipour les comparer aux valeurs connues provenant d'un matériel identique. - Rechercher le répertoire
ESP:/system32/(indicateur BlackLotus) et ungrubx64.efinon autorisé. - Extraire les modules du firmware avec UEFIExtract et comparer l'inventaire des GUID avec la référence du fournisseur.
- Vérifier les variables Secure Boot – rechercher un enrôlement MOK non autorisé ou des db/dbx modifiés.
- Vérifier la protection en écriture et les bits de verrouillage de la SPI flash à l'aide des modules chipsec.
- Scanner le dump du firmware et les modules extraits avec des règles YARA spécifiques à l'UEFI.
- Si BlackLotus est suspecté, vérifier dans le registre que HVCI est désactivé et rechercher des entrées anormales dans les journaux MeasuredBoot.
Pièges :
- Exécuter l'analyse à partir du système d'exploitation compromis (les composants du rootkit se cachent de l'analyse en direct).
- Vérifier uniquement l'ESP sans examiner le firmware SPI flash (ignore les implants au niveau du firmware comme LoJax, MoonBounce).
- Supposer que Secure Boot empêche tous les bootkits (CVE-2022-21894 et d'autres contournements existent).
- Ne pas conserver le dump original du firmware avant la remédiation (preuve médico-légale critique).
- Reflasher le firmware sans vérifier que l'image du fournisseur est authentique et non modifiée.
Format de sortie
RAPPORT D'ANALYSE DE LA PERSISTANCE DU BOOTKIT UEFI
====================================================
Système : Lenovo ThinkPad X1 Carbon Gen 11
Firmware : N3HET82W (1.54) – BIOS UEFI Lenovo
Plateforme : Intel 13e génération (Raptor Lake)
TPM : 2.0 (Infineon SLB 9672)
Secure Boot : ACTIVÉ (CONTOURNÉ via CVE-2022-21894)
Méthode d'analyse : Clé USB Linux + chipsec + UEFITool
ÉTAT DE LA PROTECTION SPI FLASH
Protection en écriture du BIOS : DÉSACTIVÉE [!]
Verrouillage SPI Flash (FLOCKDN) : DÉFINI [OK]
Protection en écriture du BIOS SMM : DÉSACTIVÉE [!]
Plages protégées SPI : Région 0 uniquement (descripteur)
ANALYSE DES VARIABLES UEFI
SecureBoot : Activé (valeur=1)
SetupMode : Désactivé (valeur=0)
PK : Lenovo Ltd. (légitime)
KEK : Microsoft + Lenovo (légitime)
db : MODIFIÉ – contient une entrée non autorisée [!]
[!] Certificat inconnu : CN=Secure Boot Signing, O=Unknown
[!] Non présent dans la base db de référence du fournisseur
MOK : 1 clé non autorisée enrôlée [!]
[!] MOK enrôlé : CN=shim, auto-signé, pas du fournisseur de distribution
ANALYSE DE LA PARTITION ESP
Binaires EFI totaux : 12
Vérifiés (signés) : 9
Modifiés (non-concordance de hachage) : 2 [!]
Non autorisés : 1 [!]
[!] EFI/Microsoft/Boot/bootmgfw.efi – MODIFIÉ
SHA-256 attendu : a3f2c8...
SHA-256 actuel : 7b1e4d...
Signature : Valide (signé avec un MOK non autorisé)
[!] EFI/Microsoft/Boot/grubx64.efi – NON AUTORISÉ
SHA-256 : e9c1a7...
Non présent dans la base de référence du fournisseur
Correspond à la signature du chargeur de démarrage de BlackLotus (étape 2)
[!] Répertoire system32/ présent sur l'ESP (artefact BlackLotus)
Répertoire vide (fichiers supprimés après l'installation)
ANALYSE DES MODULES DU FIRMWARE
Modules du firmware totaux : 312
Modules de base du fournisseur : 312
Modules ajoutés : 0
Modules modifiés : 0
Intégrité de la SPI flash : PROPRE (aucun implant au niveau du firmware détecté)
ATTRIBUTION DU BOOTKIT
Famille : BlackLotus
Confiance : ÉLEVÉE
Persistance : Basée sur l'ESP (pas de SPI flash)
Méthode de contournement : CVE-2022-21894 (baton drop)
MITRE ATT&CK : T1542.003 (Bootkit), T1553.006 (Modification de la stratégie de signature de code)
INDICATEURS DE COMPROMISSION
- Répertoire ESP:/system32/ (vide, artefact post-nettoyage)
- ESP:/EFI/Microsoft/Boot/grubx64.efi (non autorisé, chargeur BlackLotus)
- bootmgfw.efi modifié (re-signé avec le MOK de l'attaquant)
- HVCI désactivé via le registre : DeviceGuard\...\Enabled = 0
- Enrôlement MOK non autorisé dans le magasin de variables UEFI
- Journal MeasuredBoot montre EV_EFI_Boot_Services_Application pour grubx64.efi
REMÉDIATION
1. Remplacer bootmgfw.efi par une copie authentique provenant du support d'installation Windows.
2. Supprimer grubx64.efi non autorisé et le répertoire system32/ de l'ESP.
3. Réinitialiser les clés Secure Boot aux valeurs d'usine (effacer MOK, restaurer PK/KEK/db).
4. Activer la protection en écriture du BIOS et vérifier les bits de verrouillage de la SPI flash.
5. Appliquer la mise à jour du firmware vers la dernière version (corrige CVE-2022-21894).
6. Activer HVCI et vérifier via la stratégie de groupe.
7. Réimporter uniquement les certificats de confiance dans la base db Secure Boot.
8. Surveiller les journaux MeasuredBoot pour détecter des chargements anormaux de composants de démarrage.