Ce client s’est retrouvé dans le scénario classique qu’on espère ne jamais vivre : un ransomware a chiffré les données du serveur et affiché une demande de rançon en cryptomonnaie. Le point aggravant, et malheureusement fréquent, c’est que les sauvegardes n’étaient plus valides depuis environ un an. Autrement dit : au moment où on en a besoin, le “plan B” n’existe plus. C’est exactement la situation qui transforme une attaque informatique en crise réelle pour une entreprise.
Quand une rançon est demandée, la tentation est grande de payer “pour aller vite”. Il faut être très clair : on ne paye jamais. Payer ne garantit absolument pas la récupération des données, ça finance le modèle économique des criminels, et ça peut même empirer la situation (cible identifiée comme “payeur”, double extorsion, nouvelles attaques, etc.). La priorité, c’est d’isoler, sécuriser, analyser, puis restaurer proprement quand c’est possible.
Sur cette intervention, la première étape a été de contenir l’incident : couper ce qui doit l’être, éviter la propagation, et figer l’état pour ne pas aggraver les dégâts. Ensuite, diagnostic : évaluer ce qui est chiffré, ce qui est encore sain, et quels mécanismes de restauration peuvent exister malgré l’absence de sauvegarde exploitable. Dans beaucoup de cas, sans backup valide, l’entreprise est coincée. Ici, le client a eu de la chance : le serveur disposait de clichés instantanés Windows Server (Volume Shadow Copy / “versions précédentes”).
Ces clichés instantanés ne remplacent pas une vraie stratégie de sauvegarde, mais ils peuvent servir de filet de secours quand ils ont été correctement conservés et quand le ransomware n’a pas réussi à les supprimer. Ils permettent de revenir à un état antérieur des dossiers/fichiers. Concrètement, cela nous a donné une fenêtre de restauration : récupérer une version saine des données, puis remettre en service progressivement, en vérifiant l’intégrité et en s’assurant que la source de l’infection n’est plus active.
La remise en service a été faite de manière contrôlée : restauration depuis les clichés instantanés, validation des données critiques, puis reprise de l’exploitation. L’objectif n’était pas juste “que ça ré-ouvre”, mais que ce soit propre, stable et non réinfecté. À l’issue, le client a pu récupérer l’accès à ses données sans financer l’attaque.
Cette situation rappelle une règle simple : une sauvegarde qui n’est pas testée n’est pas une sauvegarde. Un système peut afficher “sauvegarde OK” pendant des mois, et le jour où on en a besoin, découvrir que c’est inutilisable. Après l’incident, une stratégie de sauvegarde fiable doit être remise en place : sauvegardes automatisées, rétention, tests réguliers, et idéalement une copie hors site ou déconnectée pour résister aux ransomwares.
