Ransomware UEFI : HybridPetya et la riposte par l’IA

En 2017, NotPetya a laissé une trace durable dans la mémoire des équipes IT : plus de 10 milliards de dollars de dégâts estimés, des chaînes logistiques à l’arrêt, des mois de reconstruction. Huit ans plus tard, ce qui m’inquiète le plus n’est pas “le retour de NotPetya”, mais ce que ses héritiers apprennent à faire mieux : frapper avant même que l’OS ne démarre.

C’est exactement ce que montre HybridPetya, un copycat repéré via des échantillons déposés sur des plateformes d’analyse. Il reprend un mécanisme historique (le chiffrement de la MFT, typique de Petya/NotPetya), et y ajoute un cran d’agressivité : l’installation d’une application EFI malveillante sur la partition système, avec, dans certaines variantes, un contournement de Secure Boot via une vulnérabilité récente.

Ce cas d’école tombe à point nommé pour notre série « Intelligence artificielle dans la cybersécurité » : quand les attaques deviennent plus “pré-OS”, plus furtives et plus techniques, la détection basée sur des signatures ou des règles statiques montre ses limites. L’IA, elle, peut repérer des motifs faibles et des anomalies sur plusieurs couches (firmware, boot, OS, réseau), et donner aux défenseurs une chance de gagner du temps.

HybridPetya, en clair : ce qui change vraiment

HybridPetya n’est pas “juste un nouveau ransomware”. Le point clé, c’est qu’il combine un comportement ransomware classique avec des techniques de bootkit UEFI.

Concrètement, les analyses publiques décrivent trois éléments différenciants :

1. Chiffrement ciblé de la MFT (NTFS) : au lieu de chiffrer chaque fichier un par un, l’attaque vise la Master File Table, un fichier de métadonnées central. Résultat : le système peut devenir inutilisable très vite.
2. Persistance et exécution au démarrage via EFI : l’attaquant place une application EFI dans la partition système EFI, et modifie le flux de démarrage pour l’exécuter.
3. Contournement de Secure Boot sur systèmes non à jour (variante) : exploitation d’une vulnérabilité de bypass sur des environnements qui n’ont pas appliqué certaines mises à jour de révocation (dbx) côté Secure Boot.

Une phrase à retenir : si le boot est compromis, “réinstaller Windows” n’est plus une solution magique.

Pourquoi le chiffrement de la MFT fait si mal

La MFT, c’est l’index de votre disque NTFS : elle relie les noms de fichiers, leurs attributs, et où se trouvent réellement les données. La chiffrer revient à rendre illisible la carte plutôt que de brûler chaque maison.

C’est une tactique efficace pour un ransomware, car elle :

• accélère l’impact (moins d’opérations que du chiffrement fichier par fichier),
• augmente le chaos côté victime (pannes, erreurs, réparation automatique),
• complique les tentatives de récupération “artisanales”.

HybridPetya utilise en plus une mise en scène connue : un faux écran de type CHKDSK pendant l’opération, pour masquer l’activité de chiffrement.

Secure Boot contourné : mythe du “socle inviolable”

Secure Boot est souvent présenté comme un verrou robuste : seules des briques de démarrage signées et approuvées doivent pouvoir s’exécuter. Dans la réalité, la chaîne de confiance dépend de plusieurs conditions : composants à jour, listes de révocation appliquées, firmwares cohérents, politiques correctes.

Le cas HybridPetya illustre une mécanique fréquente côté attaquants :

• trouver une application EFI légitime mais vulnérable, signée,
• s’en servir comme “chargeur”,
• lui faire charger une charge utile malveillante depuis un fichier spécialement formaté,
• exécuter du code non approuvé en contournant l’intention de Secure Boot.

Le message pour les RSSI est simple : Secure Boot n’est pas un produit, c’est un processus. Il fonctionne bien… quand la gouvernance des mises à jour (y compris dbx) est tenue.

Ce que les équipes IT sous-estiment souvent

J’ai vu des organisations très matures côté EDR, patch OS, segmentation… mais avec des angles morts sur la couche boot/firmware.

Trois raisons reviennent :

• responsabilité floue (poste de travail ? infra ? équipe endpoint ? équipe asset ?),
• inventaire incomplet (modèles, versions de firmware, état Secure Boot, dbx),
• peur du risque opérationnel (mise à jour firmware perçue comme “dangereuse”).

Le résultat : des machines “à jour Windows” mais en retard d’un train sur le socle de démarrage.

Pourquoi l’IA devient utile (et parfois indispensable)

Le grand problème d’un bootkit UEFI, c’est qu’il cherche à se rendre invisible à l’intérieur de l’OS : si l’étape de boot est compromise, certains signaux visibles depuis Windows peuvent arriver trop tard, ou être trompés.

L’IA apporte un avantage pratique : elle peut corréler des signaux faibles entre eux, au lieu d’attendre un indicateur unique “certain”.

Détection par anomalies : ce que l’IA repère mieux

Sur ce type d’attaque, une stratégie moderne consiste à modéliser un “normal” et à signaler les écarts. Exemples concrets (utiles même si vous n’avez pas une équipe reverse malware) :

• Écritures inhabituelles sur la partition EFI : création/modification de fichiers dans des chemins sensibles (ex. remplacement d’un bootloader, apparition de fichiers de vérification, compteurs, etc.).
• Changements dans la séquence de boot : modifications de paramètres de démarrage ou d’artefacts attendus.
• Chaînes d’événements côté endpoint : un exécutable userland qui déclenche un crash système “forcé”, puis au redémarrage un comportement anormal pré-OS.
• Incohérences cryptographiques : artefacts chiffrés ou “réécrits” de façon atypique (même sans connaître l’algorithme exact), détectables par profils d’entropie et modèles.

Une approche IA efficace n’est pas “magique” : elle combine télémétrie (endpoint + firmware + inventaire) et modèles (anomalies, graphes d’attaque, corrélation temporelle).

Distinguer “copycat” et menace active

Les analyses indiquent que HybridPetya ne montre pas (encore) de signes d’usage massif “dans la nature”. Tant mieux. Mais en défense, l’erreur classique est d’attendre la preuve d’une campagne pour se préparer.

L’IA aide sur un point précis : différencier une similarité superficielle (noms de fichiers, écrans de rançon copiés, esthétique NotPetya) d’une parenté technique (artefacts de boot, routines de chiffrement, chaînes d’exécution). C’est le genre de tri qui évite de sur-réagir… ou de sous-estimer.

Plan d’action concret pour réduire le risque (dès janvier)

Fin décembre, beaucoup d’équipes font du “gel” de changements ou tournent en effectifs réduits. Mauvaise nouvelle : les attaquants adorent ces périodes. Bonne nouvelle : vous pouvez avancer sans tout casser.

1) Verrouiller l’hygiène Secure Boot / UEFI

Objectif : rendre le bypass beaucoup moins probable.

• Vérifier l’état de Secure Boot sur le parc (pas seulement “activé”, mais cohérent avec les politiques).
• Mettre à jour les listes de révocation (dbx) via les canaux supportés (OS/constructeur), surtout sur machines anciennes.
• Normaliser les mises à jour firmware (fenêtres de maintenance, pilotes, rollback plan).

2) Surveiller la partition EFI comme un actif critique

Objectif : détecter tôt un “pré-positionnement”.

• Mettre en place une surveillance d’intégrité (hashing, listes de fichiers attendus) sur la partition EFI.
• Définir des alertes sur :
  • création de nouveaux binaires EFI,
  • remplacement/renommage de bootloaders,
  • apparition de fichiers “techniques” inhabituels.

3) Ajouter une couche IA orientée “comportements”

Objectif : attraper l’attaque même si les indicateurs exacts changent.

• Privilégier des modèles capables de corrélation (chronologie multi-événements), pas uniquement des signatures.
• Construire 5–10 règles d’anomalies simples puis itérer :
  1. écriture EFI + crash système,
  2. changement boot + fichier de config nouveau,
  3. redémarrage suivi d’un comportement disque anormal.

4) Préparer la réponse ransomware “pré-OS”

Objectif : ne pas improviser le jour J.

• Avoir une procédure “poste ne boote plus” qui inclut l’hypothèse bootkit.
• Prévoir des supports de récupération et un chemin d’investigation hors OS.
• Tester une restauration complète (firmware/boot/OS) sur un poste pilote.

Si votre PRA/PCA ransomware ne parle jamais de la partition EFI, il est incomplet.

Questions fréquentes que vos équipes vont poser

“Si on a un EDR, on est protégés ?”

Un EDR aide énormément… dans l’OS. Un bootkit UEFI cherche précisément à agir avant ou en dehors de l’OS. Il faut compléter avec de la visibilité boot/firmware et des contrôles d’intégrité.

“Est-ce que ça concerne seulement les vieux PC ?”

Non. Le bypass évoqué vise surtout des systèmes non à jour, mais l’idée “UEFI comme surface d’attaque” concerne aussi des parcs récents si la gouvernance (firmware, politiques, inventaire) n’est pas solide.

“Ça veut dire qu’on doit paniquer ?”

Non. Les signaux indiquent plutôt un cas de recherche, PoC ou préparation. Mais c’est exactement le bon moment pour corriger les prérequis (dbx, inventaire, monitoring EFI) avant qu’une campagne réelle n’explose.

Ce que HybridPetya annonce pour 2026

HybridPetya montre une trajectoire nette : les ransomwares se professionnalisent sur des couches de plus en plus basses, parce que c’est là que se trouvent la persistance, la furtivité et l’effet maximal.

La réponse qui tient la route combine deux choses :

• discipline d’ingénierie (patch, dbx, inventaire UEFI, contrôle d’intégrité),
• détection IA pour repérer les comportements anormaux quand les attaquants changent de peau (nouveaux noms de fichiers, nouveaux emails, nouveaux emballages).

Si vous travaillez déjà sur l’IA en cybersécurité, prenez HybridPetya comme exercice pratique : “Quels signaux boot/EFI ai-je, lesquels me manquent, et comment mon modèle distingue une maintenance légitime d’une compromission ?” C’est une excellente façon de transformer un sujet très technique… en plan d’action mesurable.

La question à se poser pour 2026 : quand un incident arrivera “avant Windows”, serez-vous en capacité de le voir — et de le prouver ?