UEFI Bootkit : du laboratoire à la réalité, avec un focus sur Bootkitty et BlackLotus

Les Kits de démarrage UEFI En quelques années seulement, ils sont passés du stade de concept de laboratoire à celui de véritable casse-tête pour les défenseurs et les industriels. Dans ce domaine, la frontière entre preuve de concept et menace opérationnelle est floue, et des cas comme Lotus Noir ou la récente découverte de Bootkitty sur Linux Ils le prouvent amplement.

Cet article rassemble et explique, avec langage clair et détails techniques lorsqu'elles ajoutent de la valeur, les plus pertinentes publiées par les chercheurs et les entreprises du secteur : du premier PoC en 2012 aux campagnes modernes, incluant des vulnérabilités telles que CVE-2024-7344 qui vous permettent de contourner le démarrage sécurisé, les techniques d'évasion, les IoC et les mesures de détection et d'atténuation qui fonctionnent réellement dans le monde réel.

Qu'est-ce qu'un bootkit UEFI et pourquoi est-il si problématique ?

Un bootkit UEFI est un implant qui exécute avant le système d'exploitation, avec la capacité de contrôler le flux de Botte, désactivez les vérifications et chargez les composants avec des privilèges élevés. En opérant à un niveau aussi bas, vous pouvez échapper à ces restrictions. antivirus traditionnel et même certains « mesures de démarrage en toute sécurité » s'il exploite des failles ou des configurations permissives.

Dans le monde réel, des implants et des techniques UEFI persistants ont déjà été observés, tels que LoJax, MosaïqueRégresseur o Rebond de lune, des étapes qui montrent comment un acteur peut occuper le firmware et maîtriser les phases critiques du démarrage, ce qui complique la analyse médico-légale et l'assainissement.

Défendre WindowsMicrosoft enchaîne plusieurs couches : DÉMARRAGE SÉCURISÉ (UEFI valide le chargeur avec des certificats de confiance), Botte de confiance (le noyau valide le reste des composants), ELAM (Early Launch Antimalware, qui inspecte les pilotes de démarrage) et Botte mesurée (Mesures TPM et attestation à distance). Ce sont des barrières utiles, mais pas infaillibles vulnérabilités de l'écosystème lui-même UEFI ou paramètres de confiance trop larges. De plus, il est possible fenêtres de protection avec Credential Guard, BitLocker et WDAC pour réduire le risque de persistance à long terme.

Des PoC à la vie réelle : chronologie et acteurs clés

Le voyage commence en 2012 avec le PoC de Andrea Allievi pour Windows sur UEFI, suivi de projets tels qu'EfiGuard, Boot Backdoor ou UEFI-bootkit. Il a fallu des années pour que des cas concrets, tels que ESPecteur (ESET, 2021) ou le Kit de démarrage FinSpy (Kaspersky, 2021), et en 2023, il a fait irruption sur la scène Lotus Noir, le premier bootkit UEFI capable de Contourner le démarrage sécurisé sur les systèmes entièrement mis à jourDans les environnements de laboratoire, il est courant tester des logiciels malveillants sur une machine virtuelle pour évaluer les PoC et les détections sans mettre en péril l’infrastructure productive.

Une chose était restée constante jusqu'à présent : l'objectif était ordinateurs exclusivement WindowsCette hypothèse a été brisée lorsqu'une application UEFI appelée VirusTotal est apparue sur VirusTotal en novembre 2024. bootkit.efiL'analyse a révélé un bootkit, surnommé par ses auteurs Bootkitty, conçu pour Linux (Ubuntu)Selon la télémétrie, il n'y a pas de déploiement réel confirmé ; et les auteurs eux-mêmes, liés au programme de formation coréen Le meilleur du meilleur (BoB), ils ont précisé qu'il s'agissait d'un preuve de concept dans le but de sensibiliser.

Le binaire Bootkitty est signé avec un certificat auto-signé. Cela signifie qu'il ne fonctionnera pas avec le démarrage sécurisé activé, sauf si installer les certificats de l'attaquant. Néanmoins, sa logique illustre comment un acteur peut patcher, en mémoire, des composants du chargeur (GRUB) et noyau Linux pour contourner les contrôles.

Bootkitty en détail : artefacts, compatibilité et ce qu'il modifie

Le bootkit contient des fonctions inutilisées qui impriment de l'art ASCII avec le nom Bootkitty et une liste d'auteurs possibles. Il affiche également des chaînes de texte à chaque démarrage et des références à Chat noir dans sa sortie et dans un module de noyau associé, sans rapport avec le ransomware ALPHV/BlackCat ; en partie parce que Bootkitty est écrit en C, tandis qu'ALPHV se développe dans Rust.

Sa compatibilité est limitée. Pour localiser les fonctions à toucher, utilisez modèles d'octets codés (une technique de bootkit classique), mais les modèles choisis ne couvrent pas correctement plusieurs versions du noyau ou de GRUB. Par conséquent, l'implant n'est fonctionnel que dans un nombre très limité de configurations. De plus, correctifs décalages fixes après la décompression du noyau : si les décalages ne correspondent pas à la version, cela peut écraser des données aléatoires et provoquer raccrocher au lieu de s'engager.

La botte commence par cale exécuter Bootkitty, qui interroge d'abord l'état de Démarrage sécurisé et place des hooks dans deux protocoles d'authentification UEFI : EFI_SECURITY2_ARCH_PROTOCOL.Authentification de fichier y EFI_SECURITY_ARCH_PROTOCOL.FileAuthenticationStateDans les deux cas, définissez la sortie pour renvoyer EFI_SUCCÈS, annulant ainsi efficacement la vérification de l'intégrité de l'image PE pendant la phase pré-OS.

Bootkitty charge ensuite un GRUB légitime à partir d'un chemin codé en dur sur l'ESP (/EFI/ubuntu/grubx64-real.efi), le corrige en mémoire et fonctions clés des crochets avant qu'il ne soit exécuté.

Connexion à GRUB et décompression du noyau Linux

L'implant modifie la fonction image_de_début du module image de la peau de GRUB, responsable du lancement des binaires PE déjà chargés (tels que le Stub du noyau EFI, vmlinuz.efi/vmlinuz). Profitez du fait que le noyau est déjà en mémoire et placez un hook dans la routine qui décompresse l'image réelle du noyau (probablement zstd_decompress_dctx selon la version), donc une fois décompressé, vous pouvez patch à chaud.

Il modifie également la fonction grub_verifiers_open, qui décide de vérifier ou non l'intégrité de chaque fichier chargé (modules, noyau, configuration, etc.). Le hook retourne immédiatement, et donc, évite toute vérification de signature. De son côté, l'ajustement en shim_lock_verifier_init C'est déroutant : cela force un indicateur de vérification plus strict (GRUB_VERIFY_FLAGS_SINGLE_CHUNK), mais cette fonction n'est même pas appelée par l'autre hook, laissant Hors du sujet.

Une fois le noyau décompressé, le code Bootkitty applique trois modifications de mémoire : il réécrit le chaîne de version/bannière du noyau avec le texte « BoB13 » ; forcer cela module_sig_check() renvoie 0 pour que le noyau se charge modules non signés; et remplace la première variable d'environnement du processus init injecter LD_PRELOAD=/opt/injector.so /init au début de l'espace utilisateur.

Injection par LD_PRÉCHARGER Il s'agit d'une tactique classique pour prioriser un objet partagé ELF et surcharger des fonctions. La chaîne présente ici une particularité (elle inclut « /init » à côté de LD_PRELOAD), un détail qui renforce le caractère de PoC inachevé plutôt qu'une opération soignée. Les binaires supposément injectés n'ont pas été observés, bien qu'un écrit ultérieur d'un tiers ait indiqué qu'ils ne sont utilisés que pour charger une étape supplémentaire.

Indicateurs, symptômes et un remède simple

Si Bootkitty est présent, il est possible de voir des indices visibles. La commande uname -v affichera la version du noyau avec le texte modifié et en dmesg La bannière peut également apparaître modifiée. De plus, il est possible de détecter que le processus PID 1 (init) a été publié avec LD_PRÉCHARGER inspecter /proc/1/environ, un signal anormal dans les systèmes légitimes.

Dans les tests en laboratoire, le noyau apparaît entaché après le démarrage avec Bootkitty, et une autre vérification empirique sur les ordinateurs avec Secure Boot activé consiste à essayer de charger un module non signé:Si le chargement à chaud est autorisé, cela suggère que module_sig_check a été corrigé.

Si le bootkit a été installé en remplaçant le binaire GRUB par un intermédiaire (comportement observé), un moyen simple de récupérer est de déplacer le GRUB légitime dès /EFI/ubuntu/grubx64-real.efi à son itinéraire original /EFI/ubuntu/grubx64.efi pour cale exécutez-le et la chaîne de démarrage continue sans le implant.

BCDropper et BCObserver : des pièces connectées ou une simple coïncidence ?

Un module de noyau non signé surnommé Bootkitty a été trouvé à côté de Bootkitty Compte-gouttes BC, qui partage des indices avec le bootkit : chaînes Chat noir/chat noir dans les métadonnées et les chemins de débogage, et une fonction de masquage de fichier dont les préfixes incluent « injecteur » (conformément à la variable LD_PRÉCHARGER pointant vers /opt/injector.so).

BCDropper laisse dans /opt/observer un ELF intégré (appelé BCObserver) et le lance à travers / bin / bashCe composant assez simple attend gdm3 est actif et charge ensuite un module du noyau à partir de /opt/rootkit_loader.ko à l'aide fini_module, en veillant à le faire après le démarrage complet du système.

Bien qu'il existe des indices de lien, il est impossible de garantir que les deux éléments proviennent du même auteur ou qu'ils sont conçus pour fonctionner ensemble. Pire encore, la version du noyau mentionnée dans ses métadonnées (6.8.0-48-générique) n'est même pas répertorié parmi ceux soutenus par le kit de démarrage.

IoC associés

Les artefacts suivants ont été associés aux découvertes présentées. Leur valeur est principalement référence et laboratoire :

BlackLotus et CVE-2022-21894 : le jalon qui a ouvert les vannes

BlackLotus est sur le marché depuis 2022 avec un prix d'environ 5.000 USD (plus des extras par mise à niveau) et comprend des techniques pour évasion anti-VM/anti-débogage, le géorepérage pour éviter certains pays (Arménie, Biélorussie, Kazakhstan, Moldavie, Roumanie, Russie et Ukraine) et, surtout, l'exploitation de CVE-2022-21894 (Baton Drop) pour contourner le démarrage sécurisé et obtenez une persistance robuste sur les machines Windows 10/11 entièrement corrigées.

Le flux décrit par la communauté de sécurité comprend une première phase avec désactivation des protections du système d'exploitation, l'exploitation de la vulnérabilité héritée dans Secure Boot et la enregistrement d'une clé de propriétaire de machine contrôlé par l'attaquant. Après plusieurs redémarrages, l'implant déploie un pilote du noyau et un type de composant en mode utilisateur téléchargement pour gérer la communication de commandement et de contrôle et frais supplémentaires.

Pour une défense proactive, la communauté a publié des règles opérationnelles. Par exemple, SOC Prime propose des détections Sigma qui recherchent création suspecte de fichiers de firmware dans System32 par des processus non-système ou le Désactivation du HVCI via la journalisation. Ces types de signaux, mappés sur MITRE ATT&CK (par exemple, T0857, T1562, T1112), aident à chasse aux activités anormales qui accompagne généralement les bootkits ; il existe également des guides pratiques pour Détecter les processus malveillants avec Process Explorer dans les environnements Windows.

CVE-2024-7344 : Chargement de binaires UEFI non fiables via « reloader.efi »

Une vulnérabilité particulièrement sensible a été découverte en 2024, CVE-2024-7344, qui affecte plusieurs suites de récupération signées par le certificat Microsoft Corporation UEFI CA 2011La racine du problème est l’utilisation d’un chargeur PE personnalisé dans l'application UEFI rechargeur.efi, au lieu d'API sécurisées Charger l'image/Démarrer l'image. Le binaire décrypte et exécute le contenu d'un fichier cloak.dat sans vérifier les signatures conformément à la politique de DÉMARRAGE SÉCURISÉ.

Le vecteur ne se limite pas aux ordinateurs sur lesquels le logiciel est installé, car un attaquant disposant de privilèges élevés pourrait déployer le binaire vulnérable dans l'ESP (partition EFI) de tout système qui fait confiance à l'autorité de certification UEFI tierce de Microsoft et provoque l'exécution d'une UEFI non signé au démarrage. Les produits concernés comprenaient les suites de Howyar, Greenware, Radix, SANFONG, Wasay, CES et Signal Computer, ainsi que corrigé et révoqué le 14 janvier 2025.

Pour vérifier la protection en PowerShell avec des privilèges élevés et en Linux (LVFS/dbxtool):

# ¿El sistema confía en la UEFI CA 2011 de Microsoft? (posible exposición)
::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'

# Revocación instalada (64 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'

# Revocación instalada (32 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

# Linux (dbxtool)
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

Cette affaire rouvre le débat sur la chaîne de confiance:Microsoft maintient deux certificats largement présents sur les ordinateurs UEFI grand public et d'entreprise (Windows Production CA 2011 y UEFI CA 2011 pour des tiers). Le plan en place est de migrer vers des certificats 2023, suite à des incidents tels que BlackLotus et la prolifération de chargeurs de démarrage vulnérables signés il y a des années. Sur les ordinateurs Noyau sécurisé, l'autorité de certification UEFI tierce est généralement fournie désactivé par défaut.

Protections pratiques et personnalisation de Secure Boot

Au-delà de la candidature Révocations UEFI et maintenir le firmware/OS à jour (Windows Update et LVFS), il existe des mesures qui réduisent la surface d'attaque : contrôler la accès à l'ESP avec des règles de sécurité, personnalisez DÉMARRAGE SÉCURISÉ de limiter la confiance à ce qui est nécessaire (en suivant des directives telles que celle de la NSA) et déployer attestation avec TPM pour valider à distance l'état de démarrage par rapport aux valeurs de référence.

Sous Windows, la combinaison de Démarrage sécurisé + Démarrage fiable + ELAM + Démarrage mesuré Il offre des barrières en couches : validation du chargeur, contrôleurs de démarrage inspectés avant les autres et un enregistrement signé par le TPM Ce qui permet au pare-feu de séparer les ordinateurs « propres » de ceux présentant des anomalies. Dans les environnements gérés, cela réduit le temps de détection et confinement.

Sous Linux, en plus des révocations et du contrôle ESP, il convient de surveiller des signaux tels que LD_PRÉCHARGER en le processus init, l'État entaché du noyau et corréler les événements de chargement des modules (par exemple, fini_module) avec des itinéraires inhabituels (/opt/*.ko) pour détecter les tentatives de persistance tôt.

Outils, couverture et MITRE ATT&CK

Selon ESET, c'est le seul fournisseur parmi les 20 premiers terminaux en termes de chiffre d'affaires qui intègre un Scanner de micrologiciel UEFI dans leurs solutions de protection des équipements. Bien que d'autres fabricants proposent des technologies liées à l'UEFI, leur objectif ne correspond pas toujours à la inspection directe du micrologiciel. Étant donné que les attaques UEFI, bien que sporadiques, accordent contrôle total et persistance presque absolu, investir dans cette couche peut faire toute la différence.

En termes de MITRE ATT&CK, les comportements observés correspondent à plusieurs techniques : Démarrage pré-OS : Bootkit (T1542.003), Modules partagés/LD_PRELOAD (T1129), développement de Malware (T1587.001) et utilisation de certificats (T1587.002), Plus Rootkit (T1014), Altération des défenses (T1562) y Masquer les artefacts (T1564) dans le cas des modules du noyau qui ils se cachent eux-mêmes.

• T1542.003:Bootkit sur l'ESP pour la persistance pré-OS.
• T1129: Préchargez avec LD_PRELOAD dans le processus d'initialisation.
• T1014: Modules de noyau avec fonctionnalité rootkit.
• T1562 / T1564: Désactiver les vérifications et se masquer du système.

Linux n'est pas invulnérable : l'affaire Bootkitty et de nouveaux noms sur le radar

Pendant des années, le récit populaire a opposé l'exposition accrue de Windows à la prétendue « impénétrabilité » de macOS ou LinuxLa réalité est plus nuancée : leur modèle et leur part de marché en font des cibles différentes, mais pas à l'abri. L'émergence de Bootkitty sous Linux montre que les connaissances pour créer des bootkits existent également pour cet écosystème, bien que dans ce cas précis nous parlons d'un PoC académique avec un soutien limité.

Il a même été question d’une variante de ransomware, HybridePetya, qui intégrerait les fonctionnalités du bootkit UEFI. Les échantillons téléchargés sur VirusTotal Les prévisions de 2025 en provenance de Pologne suggèrent une évolution récente, même si elles doivent être traitées avec prudence. prudence jusqu’à ce qu’il y ait une analyse indépendante et une attribution solide.

L'important est d'internaliser que la défense doit couvrir la chaîne de démarrage complète, minimiser la confiance par défaut dans signatures de tiers qui ne sont pas utilisés, surveillez la partition EFI et consolidez télémétrie utile (noyau contaminé, événements de module, modifications des vérificateurs GRUB ou variables UEFI sensibles) pour détecter à temps.

Le tableau actuel des risques liés à l'UEFI combine PoC à des fins éducatives, des bootkits commercialisés en tant que service et des vulnérabilités dans les composants signés qui, s'ils ne sont pas révoqués à temps, ouvrent la porte à exécution pré-OS non fiableMaintenir à jour les micrologiciels et les listes de révocation, réduire le cercle de confiance et surveiller l’ESP sont des mesures qui, ensemble, placent les défenseurs dans une position beaucoup plus forte contre cette famille de menaces.

Article connexe:

Comment sécuriser Windows avec Credential Guard, BitLocker, AppLocker, Device Guard et WDAC

Isaac

Écrivain passionné par le monde des octets et de la technologie en général. J'aime partager mes connaissances à travers l'écriture, et c'est ce que je vais faire dans ce blog, vous montrer toutes les choses les plus intéressantes sur les gadgets, les logiciels, le matériel, les tendances technologiques et plus encore. Mon objectif est de vous aider à naviguer dans le monde numérique de manière simple et divertissante.