Programmes malveillants
Particuliers et entreprisesDestruction malveillante de données
Wiper attack
Des données ou structures de disque sont sabotées pour empêcher la reprise.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
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 de sabotage qui rend des données ou un système inutilisables. Il peut supprimer, écraser ou endommager des structures de disque. Il faut le distinguer d’un rançongiciel conçu pour permettre un éventuel déchiffrement : l’apparence d’une demande de paiement ne prouve pas qu’une restauration par l’attaquant soit possible.
- 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.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous 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.
Un message de rançon ne prouve pas que les données ont été chiffrées de manière réversible.
À vous de décider
Une note promet de récupérer vos fichiers contre une rançon. Garantit-elle qu’un déchiffrement existe ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Non. Un programme de destruction peut imiter un rançongiciel. La reprise dépend des copies intactes et de l’état réel des supports.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Un processus détruit les structures nécessaires à la lecture des données
Le processus P9 écrit sur des zones de stockage sensibles, puis le système de fichiers devient illisible. La dernière transaction cohérente connue est T812. Un wiper cherche à détruire des données ou les structures qui permettent de les retrouver. Il peut imiter un rançongiciel, mais une note de rançon ne garantit pas 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.
Éléments à croiser
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.
Limites de l’interprétation
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
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- 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 ?
Formulez votre décision et l’élément qui la justifie 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
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-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
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des 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
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- GroupeSandworm
Repères de nommage : Unité 74455 du GRU
NotPetya : détruire sous l’apparence d’une rançon
En juin 2017, NotPetya provoque des destructions de données et des interruptions d’activité à travers le monde. Son apparence de rançongiciel ne signifie pas qu’un paiement permet de récupérer les données : le cas est un repère majeur pour comprendre les 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
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à 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 qualifier votre situation et être orienté : 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
