Pourquoi les ransomwares chiffrent aussi vos sauvegardes

« Nous avons des sauvegardes. » C’est la phrase qui rassure en comité de direction, et celle qu’on répète une fois de trop pendant une attaque, quand on découvre que les sauvegardes aussi sont chiffrées. Elle a cessé de vouloir dire grand-chose, parce qu’elle repose sur une hypothèse que les attaquants ont appris à démonter en premier.

Détruire les sauvegardes n’est pas un dégât collatéral du chiffrement. C’est l’étape qui le précède, planifiée, exécutée avec méthode, parce qu’une victime capable de restaurer ne paie pas. Une enquête indépendante menée par Vanson Bourne pour l’éditeur Sophos, auprès de près de 3 000 professionnels d’organisations victimes, le confirme : dans 94 % des attaques, les assaillants ont cherché à compromettre les sauvegardes, et ils y sont parvenus dans 57 % des cas. Le taux de tentative grimpe à 99 % dans les administrations et les collectivités locales. Pour comprendre pourquoi un dispositif ransomware de sauvegarde apparemment sérieux tombe en même temps que la production, le plus simple est de suivre une attaque depuis le point de vue des sauvegardes.

Une attaque, vue du côté des sauvegardes

Une attaque par rançongiciel réussie n’est pas un coup de tonnerre. C’est une préparation longue et silencieuse pour quelques minutes de chiffrement, et les sauvegardes sont au cœur de cette préparation.

L’entrée

L’accès initial se fait rarement en force. Aujourd’hui, il commence le plus souvent par une identité compromise : un identifiant valide récupéré par hameçonnage, acheté sur un marché spécialisé, ou rejoué depuis une fuite antérieure. Dans son enquête 2026, toujours conduite par Vanson Bourne pour Sophos, 79 % des attaques par rançongiciel débutent par une identité compromise, devant l’exploitation d’une vulnérabilité ou d’un accès distant exposé. À ce stade, rien ne se voit : l’attaquant entre avec des droits légitimes, sous une identité réelle, et ne déclenche aucune alarme.

La reconnaissance

Vient ensuite la partie la plus longue, et la moins spectaculaire. Pendant des jours, parfois des semaines, l’attaquant observe. Il cartographie le réseau, repère les serveurs de sauvegarde, les NAS, les dépôts, les tâches planifiées, les comptes de service qui font tourner les jobs. Il apprend l’infrastructure de sauvegarde, méthodiquement, parfois mieux que l’équipe qui l’exploite au quotidien. Cette latence a une conséquence qu’on mesure rarement avant qu’il soit trop tard : pendant tout ce temps, la présence de l’attaquant s’inscrit dans les jeux de sauvegarde eux-mêmes. Ses outils, ses accès dérobés, les comptes qu’il a ajoutés sont sauvegardés nuit après nuit, comme le reste. Restaurer « la veille de l’attaque » revient alors, très souvent, à restaurer l’attaquant en même temps que les données.

Les droits

Tout bascule le jour où l’attaquant obtient des droits d’administration. Il les trouve dans un compte à privilèges mal cloisonné, sur un serveur d’administration, dans un coffre d’identifiants mal protégé. À partir de cet instant, la nature de la menace change. L’attaquant n’a plus besoin de forcer quoi que ce soit du côté des sauvegardes. Il les administre. Il dispose des mêmes consoles, des mêmes API, des mêmes droits que l’équipe qui les gère. Ce n’est plus une intrusion, c’est de l’exploitation de routine.

La destruction

La suppression des sauvegardes précède le chiffrement, et elle emprunte les canaux légitimes. Les clichés instantanés du système (VSS) sont effacés d’une commande. Les snapshots, les points de restauration et les dépôts sont supprimés en passant par les API d’administration du logiciel de sauvegarde, avec des identifiants ou un jeton valides. L’opération est conforme : elle est journalisée comme une tâche d’administration ordinaire, et rien ne déclenche d’alerte. Les réplicas et les snapshots des machines virtuelles disparaissent de la même manière. Quant au NAS de sauvegarde branché en permanence et monté comme un simple lecteur, il est chiffré comme n’importe quel volume de production : partages accessibles, aucune segmentation, comptes surdotés. Rien ne le distingue, aux yeux de l’attaquant, des données qu’il vise.

Le chiffrement

Le chiffrement n’intervient qu’à la fin. Quelques minutes suffisent. Quand les écrans se figent et que les fichiers deviennent illisibles, la capacité de restauration a déjà été supprimée, souvent plusieurs heures ou plusieurs jours plus tôt. L’événement visible n’est que le dernier acte d’une pièce déjà jouée.

Ce que la chronologie révèle : un chemin d’accès, pas une faille

Reprenons la séquence. À aucun moment l’attaquant n’a eu besoin d’un exploit contre le logiciel de sauvegarde. Il a suivi un chemin d’accès qui existait déjà. Une sauvegarde classique, qu’il s’agisse d’un NAS local, d’un serveur de sauvegarde ou d’un cloud atteint via un agent joint au domaine, est joignable depuis la production et administrable avec les identités de la production. Ce n’est pas un défaut de configuration isolé, c’est la structure même du dispositif : tout ce qui est accessible depuis le réseau de production partage le sort de la production. Qui tient la production tient les sauvegardes.

La même attaque, là où elle aurait cassé

Rejouons la même séquence. À chaque étape, une décision d’architecture, et non un produit, aurait pu l’interrompre. Le principe est constant : ce qui protège une sauvegarde n’est pas sa technologie, c’est d’être hors de portée des droits de l’attaquant.

Cloisonner les identités

L’attaque bascule le jour où l’attaquant obtient des droits d’administration. C’est là que se joue l’essentiel. Des comptes de sauvegarde séparés du domaine de production, un principe de moindre privilège où le compte qui écrit les sauvegardes ne peut pas les supprimer, une authentification multifacteur sur les consoles, la journalisation et la surveillance des appels d’API : autant de cloisons qui empêchent une identité compromise côté production de devenir une identité d’administration côté sauvegarde. Une nuance s’impose ici, et elle est documentée.

Le MFA n’est pas une garantie à lui seul : dans l’enquête 2026 de Vanson Bourne pour Sophos, une forme de MFA était en place dans 97 % des incidents dont la cause racine était un identifiant compromis. Ce ne sont pas les organisations sans MFA qui tombent, ce sont les trous de couverture : une console oubliée, un accès de service exempté, un ancien portail resté ouvert.

Rendre les copies immuables

Contre la suppression elle-même, une seule chose tient : une copie qui, une fois écrite, ne peut plus être ni modifiée ni supprimée avant l’échéance fixée. C’est la logique WORM, écrire une fois et lire ensuite, appliquée aux sauvegardes. L’attaquant qui détient les droits d’administration se heurte alors à une donnée qu’aucun compte ne peut effacer, pas même le sien. Un test simple démasque les fausses promesses : si la rétention peut être levée à distance par un compte d’administration, ce n’est pas de l’immuabilité, c’est un réglage. Une immuabilité qui obéit aux administrateurs obéira à l’attaquant qui a pris leur place.

Couper le chemin d’accès : l’air gap

Reste le chemin d’accès lui-même. Ce que l’attaquant ne peut pas joindre, il ne peut pas le chiffrer. Une copie physiquement déconnectée du réseau, un air gap, retire purement et simplement les sauvegardes de son périmètre d’action. La bande magnétique sortie de son lecteur et rangée hors ligne offre cette coupure par construction : une cartouche sur une étagère n’a pas d’adresse réseau et ne s’administre pas à distance. Ce qui passe parfois pour une technologie du passé redevient, face à ce scénario précis, une garantie que peu de dispositifs connectés savent égaler.

Tester les restaurations

Dernière faille, la plus discrète : une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde, c’est une hypothèse. Tester régulièrement les restaurations vérifie deux choses à la fois, que les jeux sont exploitables, et qu’ils ne portent pas déjà l’attaquant installé pendant la reconnaissance. Retrouver un point de restauration réellement sain, antérieur à la compromission, vaut mieux que se fier à la date la plus récente.

Le cadre 3-2-1, trois copies sur deux types de supports dont une hors site, prolongé aujourd’hui par l’exigence d’une copie hors ligne ou immuable et de restaurations vérifiées, reste le repère le plus solide, à condition de le mettre à l’épreuve plutôt que de le cocher. Aucune de ces cloisons n’annule le risque à elle seule ; ensemble, elles décident de ce qui restera debout le jour où une identité d’administration bascule, et elles se doublent d’un plan de réponse à incident capable de s’exécuter sous pression.

Quand les sauvegardes sont déjà chiffrées

Une sauvegarde chiffrée n’est pas toujours une sauvegarde perdue. Selon la famille de rançongiciel en cause et l’état des supports, une analyse en laboratoire rétablit parfois l’accès à des jeux que les outils standards avaient classés comme irrécupérables. C’est le travail qui commence là où la prévention a cédé, sur des environnements de sauvegarde chiffrés qu’il faut analyser pièce par pièce.

La bonne question n’est donc plus « avons-nous des sauvegardes ? », mais une autre, moins confortable : avec les droits d’un administrateur compromis, que resterait-il ? Tout ce qu’un compte compromis peut supprimer n’est pas une sauvegarde. C’est une copie.