Analyse
Un ransomware transforme le RAID en problème logique
Un RAID peut survivre à la panne d’un disque, mais il ne protège pas contre les écritures malveillantes. Un ransomware agit au niveau logique : il chiffre, renomme, supprime ou remplace des fichiers sur le volume accessible. La redondance reproduit alors un mauvais état sur l’ensemble.
Le symptôme visible — fichiers renommés ou illisibles — relève d'abord de l'intégrité logique, même si un membre est simultanément dégradé. Remplacer ce disque ou relancer la baie ne retire aucun chiffrement ; ces opérations ajoutent des écritures et brouillent la chronologie entre attaque, panne matérielle et actions de reprise.
Il faut distinguer plusieurs couches : disques physiques, contrôleur RAID, système de fichiers, snapshots, sauvegardes, journaux et fichiers chiffrés. Chacune peut contenir une partie de la réponse, ou au contraire aggraver la confusion si elle est modifiée trop tôt.
Chez Datastrophe, la récupération de données sur RAID intervient ici sur une copie figée de la topologie, puis confronte le volume assemblé aux versions disponibles. Elle ne remplace ni la contention de l'attaque ni l'analyse de compromission menée par l'équipe de sécurité.
Le risque augmente lorsque le RAID héberge des machines virtuelles, bases métier ou partages de fichiers. Le ransomware peut modifier des conteneurs volumineux, pas seulement des documents visibles. Les données semblent parfois présentes, mais leur contenu interne est inutilisable.
Disponibilité, sécurité et récupération ont trois objectifs distincts
La sécurité cherche à contenir l'attaque et à conserver les éléments nécessaires à l'enquête. La continuité cherche un environnement sain pour reprendre. La récupération cherche les versions exploitables sans altérer les sources. Remettre le RAID en ligne peut aider la disponibilité tout en nuisant aux deux autres objectifs. Un responsable d'incident doit donc arbitrer la mise hors réseau, l'arrêt et la copie avec les équipes sécurité et métier.
Analyse
Isoler sans effacer les traces
Après détection, il faut isoler le système du réseau pour stopper les accès actifs. Mais isoler ne veut pas dire réinitialiser. Il faut éviter les nettoyages automatiques, les réinstallations et les restaurations immédiates tant que l’état n’est pas documenté.
L'isolement doit empêcher une nouvelle écriture
Débrancher le réseau coupe les accès distants, mais des processus locaux peuvent continuer à chiffrer. Éteindre brutalement peut, à l'inverse, interrompre une base, perdre des éléments volatils utiles à l'investigation ou laisser un cache RAID incohérent. Il n'existe donc pas un geste universel : si l'activité malveillante continue, la contention prime ; si elle semble arrêtée, l'équipe d'incident documente l'état avant une extinction maîtrisée.
Ne jamais reconnecter une sauvegarde saine au système suspect. Elle doit être copiée ou testée depuis un environnement isolé, avec des identifiants distincts et sans chemin d'écriture depuis l'infrastructure compromise.
Les marqueurs visibles doivent être relevés avec leur horodatage et leur origine : extensions ajoutées, note déposée, compte actif, premier fichier atteint et dernier événement connu. Les journaux exportables sont conservés séparément, sans lancer sur le volume source une indexation ou un nettoyage qui créerait de nouvelles dates.
Les disques du RAID doivent être identifiés et conservés dans leur ordre. Retirer un disque, changer une baie, forcer un import ou accepter une reconstruction peut modifier les métadonnées. Même si l’objectif est de redémarrer vite, la préservation de l’état initial compte.
Les limites de la redondance RAID apparaissent nettement dans ce scénario : chaque miroir ou bande reproduit les écritures autorisées par le système compromis. Seule une version séparée dans le temps et hors du chemin d'attaque offre un état antérieur à comparer.
Analyse
Contrôler les sauvegardes, les snapshots et les versions
Les sauvegardes sont souvent la meilleure issue, mais elles doivent être contrôlées avant restauration. Certaines peuvent être chiffrées, supprimées, trop anciennes, incomplètes ou connectées au système compromis. Une sauvegarde accessible depuis le serveur peut avoir été touchée.
| Source potentielle | Contrôle indispensable | Limite fréquente |
|---|---|---|
| Sauvegarde hors ligne | Date, périmètre, restauration isolée | Dernière version antérieure au besoin métier |
| Snapshot local | Chaîne, dépendance au volume, date | Suppression ou chiffrement sur le même stockage |
| Réplication | Moment de propagation | Mauvais état répliqué rapidement |
| Poste resté éteint | Version locale et absence de reconnexion | Copie partielle ou ancienne |
| Membres du RAID | Stabilité physique et configuration | Contenu déjà chiffré mais traces logiques utiles |
Un snapshot local conserve des blocs antérieurs seulement tant que ses dépendances et son stockage survivent. Il peut avoir été supprimé par l'attaquant ou contenir déjà les premiers changements malveillants. On vérifie donc sa chaîne, sa date réelle et la capacité à monter une copie isolée avant de le retenir comme point sain.
Restaurer trop vite peut écraser des traces utiles ou mélanger plusieurs états. Il faut d’abord déterminer la période d’attaque, les données prioritaires, l’état des sauvegardes et le niveau de confiance dans l’environnement de restauration.
La chronologie de l'incident relie découverte, premiers indicateurs, isolement, arrêts, redémarrages et essais de restauration. Dans ce dossier, elle doit aussi distinguer heure affichée par chaque système et heure corrigée, afin de ne pas choisir une sauvegarde contaminée sur la base d'horloges divergentes.
Les sauvegardes doivent être vérifiées dans un environnement isolé. Une restauration dans le même réseau ou sur le même serveur peut réexposer les données, masquer l’origine de l’incident ou écraser une version encore utile. Le contrôle doit précéder la remise en production.
Le test de sauvegarde suit un périmètre nommé : dossiers critiques, journaux d'une base, disques d'une VM, comptes techniques et clés nécessaires au redémarrage. Il mesure aussi l'écart avec le RPO accepté. Quelques documents lisibles ne prouvent ni l'absence de chiffrement dormant ni la cohérence d'une application complète.
Chercher le dernier état sain, pas seulement le plus récent
La meilleure source peut précéder l'heure visible de l'attaque : un accès initial a pu avoir lieu avant le chiffrement massif. Les journaux d'authentification, d'hyperviseur, de sauvegarde et de fichiers aident à borner cette fenêtre. Une restauration datée d'après le premier comportement suspect doit être considérée comme potentiellement contaminée jusqu'à validation.
Analyse
Éviter les reconstructions précipitées
Un RAID dégradé après ransomware demande une attention particulière. Si un disque était déjà instable avant l’attaque, le volume peut cumuler panne matérielle et chiffrement logique. Reconstruire sans analyse peut aggraver les deux.
Recréer un ensemble avec les membres d'origine, initialiser un volume ou exécuter une réparation en place impose un nouvel état de référence. Ces écritures peuvent remplacer superblocs, bitmap, journaux ou entrées de répertoire qui permettaient encore de dater et comparer les versions. L'analyse se fait d'abord sur images techniques.
Une reconstruction RAID ne déchiffre rien
Elle ne fait que rétablir la redondance à partir des membres retenus comme sources. Si ceux-ci contiennent des fichiers chiffrés, la reconstruction reproduit cet état ; si un membre ancien conserve des blocs ou métadonnées différents, l'opération peut les remplacer. L'analyse porte donc d'abord sur des copies et sur la chronologie des écritures, sans promettre que des blocs antérieurs permettront de reconstituer tous les fichiers.
Quand le volume reste partiellement accessible, il faut hiérarchiser les données. Les bases, fichiers métiers, exports comptables, machines virtuelles ou dossiers clients ne se récupèrent pas avec le même ordre de priorité. Une lecture ciblée peut être plus prudente qu’un scan complet.
Pour les environnements virtualisés, la priorité porte sur un service cohérent plutôt que sur le plus gros fichier : configuration de la VM, disques associés, snapshots, journaux et dépendances réseau ou d'annuaire. Le métier indique quelles machines peuvent être reconstruites et lesquelles contiennent une donnée irremplaçable.
Il faut également indiquer si des outils de chiffrement, d’antivirus ou de nettoyage ont été lancés après l’attaque. Même avec une intention légitime, ces opérations peuvent supprimer des fichiers temporaires, déplacer des éléments en quarantaine ou modifier les dates qui servent au diagnostic.
Analyse
Préparer un dossier exploitable
Avant toute reconstruction ou restauration, le dossier initial doit réunir :
- La topologie RAID déclarée, le contrôleur, le nombre de disques, leur ordre, leur modèle et leur numéro de série ;
- Une photographie des baies et des voyants avant tout retrait, remplacement ou acquittement d'alerte ;
- La chronologie datée de la découverte, des arrêts, redémarrages, isolements et outils déjà lancés ;
- Les marqueurs observés, notamment les extensions créées, les notes de rançon, les comptes concernés et les messages exacts ;
- L'inventaire des sauvegardes, snapshots, exports, journaux et systèmes restés hors ligne, accompagné, pour chaque source, de sa dernière date saine supposée ;
- Les données métier prioritaires et les critères qui permettront de valider une version restaurée.
Séparer la preuve technique de la reprise métier
Ces éléments réduisent l'incertitude et évitent de négliger un support secondaire qui pourrait contenir une version plus saine que le volume principal.
Le bon objectif n’est pas forcément de récupérer tout le volume. Il peut être plus pertinent de restaurer les données prioritaires, vérifier leur intégrité, puis reconstruire un environnement propre séparé du système compromis.
Le dossier RAID doit avancer sur deux voies coordonnées : contenir l'adversaire et préserver les états de stockage. Aucune reconstruction ni restauration en production n'est lancée avant d'avoir attribué les membres, borné la période suspecte et validé hors ligne un point de retour compatible avec les données prioritaires.
Le dossier transmis doit aussi préciser les contraintes d'enquête et de confidentialité. Les supports originaux, copies techniques et journaux peuvent avoir une valeur probatoire ; leur origine, leur date et les manipulations réalisées doivent rester traçables. La récupération de fichiers ne remplace ni l'analyse de compromission ni les obligations de notification qui pourraient s'appliquer.
La restitution est injectée dans une infrastructure reconstruite et contrôlée, avec des identifiants renouvelés selon le plan de réponse. L'ancien RAID reste isolé pour les besoins techniques ou probatoires. Le reconnecter avant traitement de la cause peut réactiver le chemin d'attaque et contaminer les versions restaurées.
Sources techniques primaires et limites
La documentation du noyau Linux sur les ensembles MD décrit superblocs, rôles, assemblage et états d’un RAID logiciel. Elle ne permet pas d’appliquer automatiquement une géométrie ou une génération à une baie propriétaire, et ne justifie aucune reconstruction sur les membres originaux.
Faire qualifier le dossier « RAID après ransomware : préserver les données »
Transmettez à Datastrophe tous les membres actifs, retirés et de secours avec leur ordre de slot, le contrôleur et son cache, les configurations, les cartes d’erreurs et les volumes prioritaires. Les codes, clés et éléments d’authentification autorisés sont communiqués par un canal distinct ; ils ne sont jamais inscrits sur le support ni dans le colis.
Datastrophe réalise directement le diagnostic, les contrôles d’intégrité et la récupération dans son laboratoire, avec sa propre équipe. Le diagnostic et le devis sont gratuits. Le transport privé aller et retour est systématiquement pris en charge ; le transporteur déplace uniquement le colis scellé, sans accéder aux données ni les traiter.
Avant tout paiement, le client reçoit le prix proposé et une liste contrôlée. Chaque élément y est classé, dans cet ordre, recoverable_verified, partial, detected_unverified ou unrecoverable. Seuls les éléments recoverable_verified, dont le contenu a été contrôlé et jugé exploitable, sont présentés comme récupérables. Le client paie seulement après avoir accepté la liste et le prix ; la préparation du résultat et la restitution interviennent ensuite.
Si aucune donnée exploitable n’est vérifiée, si la récupération échoue ou si le client refuse la liste ou le prix, aucun frais standard n’est dû. La seule exception concerne une pièce rare, coûteuse et non remboursable : elle ne peut être commandée qu’après une proposition séparée, explicite et chiffrée.