Bootkit.

Un bootkit est un rootkit spécialisé qui compromet les composants précoces du démarrage — le Master Boot Record (MBR), le Volume Boot Record (VBR) ou le firmware UEFI — de sorte qu'il s'exécute avant le système d'exploitation et ses outils de sécurité. Depuis cette position, il peut désactiver les défenses, accrocher le noyau et survivre aux réinstallations de l'OS. Les bootkits MBR historiques (TDL4/Alureon, Rovnix, le chargeur chiffreur de disque de Petya) ont cédé la place aux implants de l'ère UEFI qui ciblent les variables NVRAM et la partition système EFI.

Où se loge un bootkit dans la chaîne d'amorçage

flowchart LR
  A[Mise sous tension] --> B[Firmware UEFI<br/>flash SPI]
  B --> C[Secure Boot<br/>vérifie les signatures]
  C --> D[Gestionnaire d'amorçage<br/>bootmgfw.efi]
  D --> E[Chargeur OS / noyau]
  B -. implant firmware<br/>MoonBounce/LoJax .-> B
  C -. exploit CVE-2022-21894<br/>contournement de Secure Boot .-> D
  D -. .efi malveillant sur la<br/>partition système EFI .-> D
  E --> F[OS + outils de sécurité<br/>chargés en dernier, déjà subvertis]

Exemples connus

LoJax (ESET, 2018) fut le premier rootkit firmware UEFI observé dans la nature, attribué à Sednit/APT28. MoonBounce (2022) se dissimulait dans la flash SPI. BlackLotus (2023) est devenu le premier bootkit à vaincre UEFI Secure Boot sur un Windows 11 entièrement à jour : il « apporte ses propres » binaires d'amorçage vulnérables mais signés pour exploiter CVE-2022-21894 (« Baton Drop »), puis désactive HVCI, BitLocker et Defender. Comme les binaires vulnérables restaient valablement signés, le correctif de Microsoft a nécessité une révocation — une politique d'intégrité du code dans les mises à jour de mai 2023, avec des ajouts à la DBX (et plus tard les recommandations KB5025885), qui risquaient de rendre inutilisables les supports en double amorçage si elle était appliquée sans précaution.

Détection et atténuation

Activez UEFI Secure Boot avec des listes de révocation DBX à jour, appliquez des mots de passe firmware/BIOS, désactivez le CSM hérité et utilisez un démarrage mesuré adossé au TPM avec attestation distante. La détection nécessite généralement une imagerie forensique hors ligne de la flash SPI et de l'ESP, car un OS déjà subverti et en cours d'exécution ne peut être considéré comme fiable pour rendre compte de sa propre chaîne d'amorçage.