HybridPetya : conduite à tenir

Ce document s'adresse à une victime ou à un intervenant face à une machine affichant le faux « CHKDSK » ou l'écran de rançon d'HybridPetya (« Ooops, your important files are encrypted », 1000 dollars, contact wowsmith123457@proton.me). Il découle du billet HybridPetya.

1. Ce qu'il ne faut pas faire#

• Ne pas réinstaller Windows ni réparer le démarrage. La récupération sans clé a besoin des fichiers verify et counter de la partition système EFI (ESP), et du disque tel quel.
• Ne pas lancer CHKDSK ni d'outil de réparation NTFS. Ils réécriraient un $MFT qu'ils jugent corrompu.
• Ne pas payer. Le chiffrement du disque par le bootkit UEFI se défait sans la clé (§3 ci-dessous). Les fichiers chiffrés en mode utilisateur, eux, ne se récupèrent qu'avec la clé de l'opérateur, et rien ne garantit qu'elle serait fournie.
• Si l'écran de saisie de clé du chemin BIOS est utilisé (disque MBR), une seule faute de frappe suffit pour que la bonne clé soit ensuite refusée : il faut redémarrer avant chaque nouvel essai, et saisir la clé en minuscules.

2. Identifier la situation#

Éteindre la machine, puis démarrer sur un support externe ou monter le disque sur une autre machine en lecture seule.

La règle HybridPetya_ESP_Config de hybridpetya.yar reconnaît le fichier config (portefeuille à l'offset 0x29).

Si l'état vaut 0, le $MFT n'est pas encore chiffré. Avant tout redémarrage sur le disque, remplacer \EFI\Microsoft\Boot\bootmgfw.efi par le gestionnaire de démarrage d'origine : bootmgfw.efi.old, dont ESET indique que les 0x400 premiers octets sont masqués par XOR 0x07 dans la variante Secure Boot, ou une copie saine issue d'un support d'installation Windows de même version. Restaurer aussi \EFI\Boot\bootx64.efi.

3. Récupérer un disque chiffré par le bootkit UEFI#

1. Préserver les preuves. Copier l'ESP entière, et en particulier config, verify et counter. Faire une image complète de la partition NTFS chiffrée, et ne travailler que sur des copies.
2. Disposer d'un volume NTFS sain quelconque (une clé USB formatée en NTFS suffit). Il sert seulement de modèle générique d'enregistrement $MFT.
3. Lancer l'outil sur la copie :

recover_mft_without_key.py partition_chiffree.img verify reference.img partition_restauree.img --counter counter

L'outil affiche la méthode employée et la part d'enregistrements cohérents après déchiffrement. Avec la méthode exacte (« clusters nuls chiffrés »), le résultat est complet. Avec la méthode statistique, vérifier la cohérence annoncée et contrôler le volume restauré en lecture seule. 4. Vérifier puis exploiter l'image restaurée : montage en lecture seule, contrôle de l'arborescence, puis copie des données vers un support sain. 5. Remettre en état le démarrage, après extraction des données : restaurer bootmgfw.efi et bootx64.efi d'origine, supprimer config, verify, counter, cloak.dat et cloak64.dat. Une réinstallation propre reste préférable, la machine ayant exécuté du code malveillant avec les droits administrateur.

Si le $MFT est très fragmenté, le bootkit a pu chiffrer aussi des clusters de données, voire balayer le reste du volume. L'outil recalcule exactement les clusters touchés et les restaure également : il faut lui fournir l'image de la partition entière, pas seulement le $MFT.

4. Disque MBR (chemin BIOS)#

Le chemin BIOS reprend le chargeur de NotPetya avec son défaut de flux de période 4 Mio. Les méthodes publiées pour NotPetya s'appliquent ; aucun outil spécifique n'est fourni ici. Préserver les secteurs 0 à 0x22, et notamment le secteur 0x22 qui contient le MBR d'origine masqué par XOR 0x07.

5. Fichiers chiffrés en mode utilisateur#

AES-256-CBC, clé protégée par ECDH avec la clé publique de l'opérateur : pas de récupération possible sans cette clé privée. Restaurer depuis des sauvegardes, les clichés instantanés de volume s'ils existent, ou conserver les fichiers chiffrés au cas où un déchiffreur deviendrait disponible. Le pied de 0x76 octets ajouté à chaque fichier contient l'IV et la clé d'installation à fournir le cas échéant.

6. Prévention et détection#

• Appliquer les mises à jour de la base de révocation Secure Boot (DBX) : reloader.efi y figure depuis le 2024-11-01. Vérifier sa présence avec l'empreinte Authenticode cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48.
• Laisser Secure Boot activé : le bootkit installé directement n'a aucune signature et le micrologiciel refuse de le charger. Windows ne démarre plus tant que bootmgfw.efi n'est pas restauré (§2), mais le $MFT n'est pas chiffré.
• Surveiller les écritures sur l'ESP et la modification de \EFI\Microsoft\Boot\bootmgfw.efi par un processus autre que le système de mise à jour Windows.
• Surveiller l'appel NtRaiseHardError avec le statut 0xC0000350 utilisé pour provoquer l'écran bleu.
• Déployer hybridpetya.yar sur les fichiers, la mémoire et, pour la règle du chargeur 16 bits, les premiers secteurs des disques.
• Indicateurs complets : iocs.csv.