Vous avez payé la rançon, obtenu la clé ou téléchargé un outil de déchiffrement gratuit publié par un chercheur en sécurité, et pourtant vos fichiers restent inexploitables. Ce scénario est plus fréquent qu’on ne le pense. Sur des formats complexes comme les bases de données SQL ou les fichiers de machines virtuelles (VHDX, VMDK), un déchiffrement qui laisse la structure interne corrompue est un résultat courant, pas un cas isolé : un bug documenté du déchiffreur du ransomware Ryuk, par exemple, tronquait d’un octet la fin des fichiers volumineux (conteneurs VHD/VHDX, bases Oracle et SQL Server), ce qui suffisait à empêcher tout montage malgré un contenu quasiment intégralement déchiffré. Les données sont techniquement déchiffrées au niveau binaire, mais la structure logique du fichier reste corrompue et le système refuse de démarrer.
Ce qui se passe concrètement lors d’une attaque par ransomware
Lorsqu’un rançongiciel touche un serveur d’entreprise, il ne se contente pas de bloquer l’accès à quelques fichiers isolés. Il chiffre en profondeur les données critiques : bases de données SQL, disques de machines virtuelles, archives et documents de production. Chaque fichier est réécrit selon un algorithme de chiffrement, souvent en quelques minutes seulement pour les volumes les plus lourds, ce qui explique pourquoi les journaux d’événements montrent une activité disque anormale juste avant que les extensions des fichiers ne changent.
Une fois l’attaque terminée, une note de rançon apparaît généralement dans plusieurs dossiers, avec des instructions de paiement et parfois la promesse d’un outil de déchiffrement fonctionnel une fois la somme versée. C’est à ce moment que beaucoup d’entreprises pensent avoir trouvé une solution rapide. La réalité de la restauration, elle, est nettement plus incertaine.
Pourquoi payer la rançon ne garantit pas une récupération complète
Obtenir une clé de déchiffrement, que ce soit via le paiement de la rançon ou grâce à un outil publié gratuitement par un chercheur en sécurité, ne garantit jamais une restauration intégrale des données. Le paiement ne garantit ni la remise d’un outil réellement fonctionnel, ni une récupération complète, ni même l’absence d’un nouveau ciblage dans les mois qui suivent. Sur des fichiers structurés complexes, l’échec partiel du déchiffrement n’est pas une exception documentée par quelques cas rares : c’est un scénario que les laboratoires de récupération observent régulièrement.
Des outils développés dans l’urgence, pas testés en conditions réelles
Les outils de déchiffrement fournis par les cybercriminels après paiement sont développés rapidement, sous pression, avec pour seul objectif de prouver que le déchiffrement est possible. Ils sont rarement conçus pour gérer proprement les cas limites : gros fichiers, formats fragmentés, écritures interrompues en cours de chiffrement. Résultat, ils fonctionnent souvent correctement sur des fichiers simples (documents bureautiques, images) mais deviennent instables dès qu’ils rencontrent des structures de données plus complexes.
Le cas particulier des bases de données et des machines virtuelles
Une base de données SQL n’est pas un simple flux de données à déchiffrer bloc par bloc. Elle contient des index, des pages internes, des relations entre tables, qui doivent rester parfaitement cohérents pour que le moteur de base de données puisse la relire. Il en va de même pour un fichier de machine virtuelle VHDX ou VMDK, dont l’en-tête et la table d’allocation doivent correspondre exactement au contenu du disque virtuel. Un déchiffreur qui traite le fichier comme un bloc binaire uniforme, sans respecter ces structures internes, peut laisser la quasi-totalité du contenu techniquement déchiffré tout en rendant la base ou la VM totalement inexploitable : un simple décalage d’un octet dans l’en-tête ou la table d’allocation suffit à rendre le fichier illisible. Certains groupes de cybercriminels proposent un support technique après paiement, dans un souci de « réputation » qui les pousse à maintenir des victimes payantes à l’avenir — mais ce service reste à leur entière discrétion, sans aucune garantie de résultat ni recours juridique possible s’il échoue à résoudre votre cas.
Déchiffrement et récupération de données : deux problèmes différents
C’est le point le plus mal compris dans ce type de situation. Le déchiffrement consiste à retrouver le contenu en clair d’un fichier chiffré : c’est un problème cryptographique. La récupération de données consiste à reconstruire une structure de fichier exploitable par le système ou l’application concernée : c’est un problème de structure et d’intégrité. Un fichier peut être parfaitement déchiffré au sens cryptographique et rester inutilisable au sens applicatif, parce que ses en-têtes, ses index ou ses tables internes n’ont pas été remis en cohérence pendant l’opération. C’est exactement ce qui se produit sur les bases SQL et les fichiers de VM après un déchiffrement automatisé mal maîtrisé.
Ce qu’il ne faut pas faire en cas de déchiffrement partiel ou raté
Face à un résultat décevant, le premier réflexe est souvent de relancer l’outil en boucle en espérant un meilleur résultat, ou de tenter une réparation avec des utilitaires SQL génériques trouvés en ligne. Ces deux réflexes aggravent presque toujours la situation.
- Ne relancez pas le déchiffreur plusieurs fois de suite sur les mêmes fichiers : chaque passage peut écraser les dernières structures encore exploitables.
- N’essayez pas de réparer vous-même une base de données endommagée avec un outil de réparation SQL standard : ces outils supposent une corruption classique, pas une structure altérée par un déchiffrement partiel, et risquent de supprimer des données encore récupérables.
- Clonez ou sauvegardez l’état actuel des fichiers avant toute nouvelle tentative, y compris les fichiers partiellement déchiffrés : c’est souvent la seule copie exploitable qui reste.
- Conservez également une copie des fichiers chiffrés d’origine et de la clé obtenue, au cas où une nouvelle version de l’outil de déchiffrement serait nécessaire par la suite.
La démarche professionnelle face à un déchiffrement raté
Là où un outil de déchiffrement automatisé s’arrête, une intervention manuelle au niveau binaire et hexadécimal peut prendre le relais. Il s’agit d’analyser directement la structure du fichier : repérer les tables SQL, les en-têtes de VM ou les index qui n’ont pas été correctement remis en cohérence, puis reconstruire ces éléments un par un à partir de ce qui reste exploitable dans le fichier partiellement déchiffré. Cette approche demande une bonne connaissance du format de fichier concerné (moteur SQL utilisé, version du format VHDX ou VMDK) et des outils adaptés à ce niveau d’analyse, très différents des utilitaires de réparation grand public.
Un laboratoire spécialisé en récupération de données sur serveur commence généralement par un diagnostic pour déterminer précisément où se situe la rupture entre les données techniquement déchiffrées et la structure logique attendue. Ce diagnostic permet de savoir si une reconstruction est possible avant d’engager toute manipulation supplémentaire sur les fichiers, ce qui évite de perdre du temps sur une piste qui n’aboutirait pas.
Ce qu’il faut retenir
Obtenir une clé de déchiffrement, par le paiement d’une rançon ou par un outil gratuit, n’est que la première étape. Sur des fichiers complexes comme les bases de données et les machines virtuelles, un déchiffrement partiel qui laisse la structure interne corrompue est un résultat fréquent, pas un accident isolé. Le bon réflexe n’est pas d’insister avec l’outil d’origine ni de tenter une réparation générique, mais de préserver l’état actuel des fichiers et de faire appel à une expertise capable de reconstruire les structures internes au niveau binaire. C’est cette étape, distincte du déchiffrement lui-même, qui détermine si vos données redeviennent réellement exploitables.