Programmes malveillants
Particuliers et entreprisesDestruction malveillante de données
Wiper attack
Un programme détruit les données ou abîme l’organisation du disque pour empêcher la reprise.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
Des postes ne démarrent plus ou des données sont remplacées par des contenus inutilisables. Un message peut évoquer une rançon, mais aucun mécanisme de récupération fiable n’existe nécessairement. L’objectif principal peut être de détruire et de perturber l’activité.
Comment cela fonctionne
Un wiper est un programme conçu pour saboter des données ou rendre un système inutilisable. Il peut supprimer ou écraser des fichiers, ou endommager l’organisation du disque. Contrairement à un rançongiciel prévu pour permettre un éventuel déchiffrement, il peut détruire sans possibilité de retour par l’attaquant. Même si un message réclame de l’argent, rien ne prouve que son auteur puisse restaurer les données.
- Un accès d’écriture est obtenu
Données ou systèmes sont atteignables.
- Le contenu est saboté
Suppression, écrasement ou structure détruite.
- La reprise dépend des copies
L’accès malveillant doit aussi être supprimé.
Les signes qui doivent attirer l’attention
- Des suppressions ou écrasements massifs surviennent.
- Plusieurs systèmes perdent simultanément leur capacité de démarrage.
- Des accès à des disques ou outils d’administration précèdent la destruction.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Conservez des copies séparées. Si des données ont été détruites, évitez les réparations répétées sur le support original et demandez une assistance pour préserver ce qui reste récupérable.
Si vous êtes responsable du service ou de l’organisation
Protégez les sauvegardes contre les comptes capables d’effacer la production. Testez la reconstruction dans un environnement séparé et vérifiez la cohérence des données restaurées.
Une demande de rançon ne garantit pas que les données aient été chiffrées d’une façon qui permette de les récupérer.
À vous de décider
Une note promet de récupérer vos fichiers contre une rançon. Garantit-elle qu’un déchiffrement existe ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Un outil de destruction peut afficher une fausse demande de rançon. La reprise dépend des copies restées intactes et de l’état des supports.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Un processus détruit les structures nécessaires à la lecture des données
Après des écritures du processus P9 sur des zones sensibles du stockage, le système de fichiers devient illisible. La dernière transaction cohérente connue est T812. Un wiper détruit des données ou les structures qui permettent de les retrouver. Il peut afficher une demande de rançon sans qu’un déchiffrement soit possible.
Il faut déterminer ce qui a été altéré : fichiers, métadonnées du système de fichiers, table de partition ou autre composant. Une erreur de disque, un incident de contrôleur ou un outil d’administration mal utilisé peuvent produire une partie des mêmes symptômes. Relier les écritures au processus, au compte et aux commandes observées, sans travailler directement sur l’unique copie du support endommagé.
La reprise dépend des copies intactes et de leur indépendance par rapport aux accès compromis. Une sauvegarde déclarée réussie n’est pas une preuve de restauration possible. Préserver les éléments utiles, arrêter les écritures destructrices et tester la reconstruction dans un environnement séparé. Les identités et outils d’administration utilisés pour détruire les données doivent être traités avant de reconnecter les systèmes restaurés.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Écritures destructrices
Identité / processus vers Stockage
Trace audit et périmètre
- Action sur place
Structures illisibles
Stockage
Trace erreurs de métadonnées
- Action
Acquisition conservatoire
Stockage vers Copie préservée
Trace avant réparation
- Action sur place
Analyse des transformations
Copie préservée
Trace réversibilité à établir
- Action
Restauration isolée
Copie préservée vers Application restaurée
Trace point T812
- Action sur place
Validation transactionnelle
Application restaurée
Trace dépendances métier
- Refus / blocage
Accès aux copies interdit
Identité / processus vers Copie préservée
Trace séparation des identités
Comment repérer cette attaque
Indices à rechercher
Rechercher les écritures anormales sur les périphériques et métadonnées, les suppressions massives et les accès inhabituels aux sauvegardes.
Quelles informations comparer
Mettre en regard première écriture anormale, premières erreurs de lecture et dernière transaction validée. Déterminer la fenêtre de perte avant de choisir un point de restauration.
Ce que ces indices ne permettent pas de conclure
Des erreurs de disque peuvent venir d’une panne matérielle. La destruction volontaire exige des indices sur les écritures ou le programme responsable ; éviter les opérations de réparation qui écraseraient les preuves.
Comment réagir
Stopper la propagation et protéger les copies hors d’atteinte des identités compromises. Préserver les supports et journaux avant réparation. Reconstruire l’infrastructure de confiance puis restaurer à un point cohérent vérifié ; documenter les pertes irrécupérables sans les masquer derrière un retour du service.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- La restauration récupère des données lisibles et cohérentes, au-delà d’un simple contrôle d’empreinte.
- Les sauvegardes restent hors de portée des identités compromises.
- Les systèmes restaurés sont vérifiés avant reconnexion et les pertes restantes sont documentées.
À vous de raisonner
Une note de rançon accompagne un stockage devenu illisible. Quelle hypothèse faut-il garder ouverte pour préparer la reprise ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Les données ou leurs structures peuvent avoir été détruites, sans possibilité de déchiffrement. Préservez le support et analysez une copie ; vérifiez des sauvegardes indépendantes dans un environnement séparé. L’apparence de rançongiciel ne prouve pas l’existence d’une clé de récupération.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
last_consistent_transaction- Repère fourni par l’application métier dans ce cas, et non numéro universel déductible du journal de stockage.
immutable- Propriété à vérifier dans la configuration de sauvegarde et ses droits, pas garantie apportée par un simple libellé de log.
Écritures et panne
JournalTraces synthétiques ; les offsets et données réelles ne sont pas exposés.
storage host=S4 writer=P9 region=metadata writes=high
filesystem host=S4 errors=metadata_unreadable
application host=S4 last_consistent_transaction=T812
backup copy=B8 immutable=true last_restore_test=2026-09-10Préparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Linux — auditd
- Où les trouver
- Sur le serveur concerné, dans le fichier log_file d’auditd, généralement /var/log/audit/audit.log. Les enregistrements SYSCALL, EXECVE et PATH d’un même événement partagent le numéro dans msg=audit(...).
- Quoi relever
- Si le système reste lisible et les règles existaient, rechercher les accès et processus ayant touché les fichiers ou périphériques concernés. Conserver les copies distantes : les journaux locaux peuvent avoir été détruits.
- Accès et prérequis
- Service actif et règles d’audit adaptées avant les faits. Linux n’enregistre pas automatiquement toutes les exécutions et lectures ; les arguments et chemins collectés peuvent être sensibles.
Veeam Backup & Replication — journaux de sauvegarde
- Où les trouver
- Console → menu principal → Help → Support Information : sélectionner le job ou composant et la période concernés. Conserver aussi l’historique de la tâche de restauration effectivement testée.
- Quoi relever
- Retrouver les points conservés hors du système atteint, les erreurs éventuelles et les résultats de tests de restauration. Vérifier séparément la configuration d’immutabilité et qui pouvait la modifier.
- Accès et prérequis
- Accès habilité à la console. L’emplacement local dépend du composant et de la plateforme ; un autre logiciel de sauvegarde nécessite son export équivalent. Protéger les archives contenant configuration et noms de machines.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Récupérer auprès des exploitants les erreurs du stockage et du système de fichiers, le dernier identifiant de transaction métier cohérent, puis les journaux et tests des sauvegardes hors du système atteint.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- GroupeSandworm
Noms et appellations : Unité 74455 du GRU
NotPetya : détruire sous l’apparence d’une rançon
En juin 2017, NotPetya détruit des données et interrompt des activités à travers le monde. Il ressemble à un rançongiciel, mais cette apparence ne garantit pas qu’un paiement permettrait de récupérer les fichiers. Ce cas aide à comprendre les programmes de destruction appelés wipers.
Ce qu’établit la source. L’acte d’accusation américain de 2020 attribue l’opération à l’unité militaire associée à Sandworm. Une accusation est distinguée d’un jugement.
Consulter le rapport Six Russian GRU Officers ChargedU.S. Department of Justice · Publié le
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’aucun de ces groupes.
Si vous pensez être concerné
- Faites contenir rapidement la propagation et protégez les sauvegardes.
- Évitez les écritures et tentatives répétées de réparation sur un support à expertiser.
- Organisez la reprise depuis des copies fiables avec l’aide de professionnels compétents.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Data Destruction — attack.mitre.org
- MITRE ATT&CK — Disk Wipe — attack.mitre.org
