Ransomwares : Pourquoi Vos Sauvegardes Vous Trahissent

Les ransomwares de 2026 ne chiffrent plus vos données en premier — ils détruisent vos sauvegardes. C'est leur première étape, systématique, méthodique, industrialisée. Avant même de lancer leur payload de chiffrement, les groupes modernes comme LockBit 4.0, BlackCat ALPHV ou Interlock passent des jours voire des semaines à cartographier et neutraliser votre stratégie de backup. Ils cherchent vos agents Veeam, vos snapshots VMware, vos sauvegardes cloud, vos NAS et vos Volume Shadow Copies. Ils les suppriment un à un, silencieusement, avant de déclencher le chiffrement. Si vous pensez que votre plan de reprise d'activité vous protège parce que vous avez des sauvegardes à 30 jours de rétention, cet article va vous déranger — et c'est exactement l'objectif. La résilience face aux ransomwares modernes nécessite une refonte complète de votre approche backup, bien au-delà de la simple règle 3-2-1.

Ce que font réellement les ransomwares modernes avant de chiffrer

En 2024-2025, j'ai eu l'occasion d'analyser plusieurs incidents ransomware post-compromission dans le cadre de missions forensiques. Ce qui m'a frappé à chaque fois : les attaquants avaient passé entre 3 et 21 jours dans le réseau avant de déclencher le chiffrement. Durant cette phase de reconnaissance active, leur objectif principal n'était pas d'exfiltrer des données — c'était de comprendre et neutraliser la stratégie de sauvegarde de l'organisation.

Voici ce qu'ils font concrètement. Ils identifient vos solutions de backup en analysant les processus actifs et les connexions réseau. Ils repèrent vos snapshots VMware et vos points de restauration Windows. Ils localisent vos NAS et vos serveurs de sauvegarde en scannant les partages SMB. Et ensuite, ils suppriment tout ça — avant de chiffrer. Le groupe LockBit 4.0 a publié dans sa documentation interne une checklist explicite de neutralisation des sauvegardes. Ce n'est pas un hasard, c'est une méthodologie industrialisée. Les techniques les plus fréquemment observées : suppression des Volume Shadow Copies via vssadmin delete shadows /all /quiet, désactivation des agents de backup via les services Windows, corruption silencieuse des fichiers de sauvegarde, et dans les cas les plus sophistiqués, chiffrement ou suppression des sauvegardes stockées sur des partages réseau accessibles. La CISA documente cette tactique dans son guide StopRansomware comme l'une des plus critiques à contrer. Consultez également notre analyse de l'incident Marquis Financial pour un exemple concret des conséquences.

Les erreurs de backup que j'observe systématiquement en audit

Première erreur, et la plus répandue : les sauvegardes accessibles depuis le domaine Active Directory. Si votre serveur Veeam est membre du domaine et que l'attaquant a compromis un compte admin de domaine, il a accès à vos sauvegardes. C'est aussi simple que ça. J'ai vu des organisations avec des budgets IT significatifs faire cette erreur fondamentale. Le serveur de backup doit être soit physiquement isolé, soit dans un domaine séparé avec des credentials dédiés non exposés sur le réseau principal. Notre guide du Tiering Model Active Directory explique comment cloisonner correctement ces accès.

Deuxième erreur : la règle 3-2-1 mal appliquée. Trois copies, deux médias différents, une hors-site — en théorie c'est bien. En pratique, je constate que le "hors-site" est souvent un NAS synchronisé en temps réel via un tunnel VPN sur le même réseau. Ce n'est pas une sauvegarde hors-site, c'est une deuxième cible. Troisième erreur : ne jamais tester la restauration. Des backups qui existent sur le papier mais qui échouent à la restauration, j'en vois régulièrement. La validation de l'intégrité des sauvegardes doit être automatisée et testée en conditions réelles au moins trimestriellement. Pour comprendre comment les attaquants se déplacent latéralement avant d'atteindre vos backups, notre guide de pentest Active Directory vous donnera la perspective de l'attaquant. Voir aussi notre guide sur la sécurisation Active Directory pour les défenses structurelles.

La stratégie de backup qui résiste aux ransomwares en 2026

Voici ce que je recommande dans mes missions, basé sur ce qui fonctionne réellement face aux groupes modernes. D'abord, l'air gap physique ou logique : au moins une copie de sauvegarde doit être inaccessible depuis le réseau de production. Bandes magnétiques (LTO), disques durs déconnectés, ou stockage cloud avec authentification multi-facteurs et période de rétention avec suppression différée (les buckets S3 avec S3 Object Lock sont une bonne option). Ensuite, les sauvegardes immuables : certaines solutions comme Veeam Hardened Repository, Cohesity ou Rubrik permettent de créer des sauvegardes que même l'administrateur ne peut pas supprimer pendant la période de rétention définie. C'est la réponse technique directe à la neutralisation des VSS. Enfin, le monitoring des sauvegardes : alertes immédiates si un processus tente de supprimer les VSS, si l'agent de backup est arrêté, si les jobs de backup échouent plusieurs fois consécutives. Ces événements sont des signaux d'alarme ransomware à traiter comme des incidents critiques. Consultez le guide ransomware de la CISA pour les bonnes pratiques détaillées.

FAQ

Qu'est-ce que Ransomwares ?

Le concept de Ransomwares est détaillé dans les premières sections de cet article, qui couvrent les fondamentaux, les enjeux et le contexte opérationnel. Pour un accompagnement sur ce sujet, contactez nos experts.

Conclusion

Les ransomwares modernes ont fait de la neutralisation des sauvegardes une étape systématique et méthodique de leur chaîne d'attaque. Une stratégie de backup conçue uniquement pour faire face aux pannes matérielles ou aux suppressions accidentelles ne résiste pas à un attaquant déterminé. La résilience face aux ransomwares exige un niveau supplémentaire de conception : isolation physique ou logique, immuabilité, surveillance active et tests réguliers en conditions adverses. Si votre PCA n'a pas été révisé avec cette réalité en tête, il ne vous protège pas — il vous donne juste une fausse sensation de sécurité.

Sources et références : CERT-FR · MITRE ATT&CK

Mettre en place une gouvernance backup orientée résilience ransomware

Au-delà des mesures techniques, la résilience face aux ransomwares exige une gouvernance backup spécifique. Cela commence par un propriétaire clairement identifié pour la stratégie de sauvegarde — pas le responsable IT généraliste, mais un rôle dédié avec des responsabilités explicites sur les objectifs de RTO (Recovery Time Objective) et RPO (Recovery Point Objective) face à un scénario ransomware. Ces objectifs doivent être régulièrement testés et documentés, pas simplement définis sur le papier. La gouvernance inclut également un processus de validation des sauvegardes indépendant de l'équipe qui les gère — pour éviter que les mêmes personnes qui gèrent les backups soient aussi celles qui valident leur intégrité, créant un angle mort organisationnel. Pour structurer votre approche globale de sécurité avec ce type de rigueur, consultez notre guide sur l'audit et le monitoring de l'infrastructure IT et notre analyse des implications réglementaires de la sécurité des données — la perte de données suite à un ransomware engage aussi la responsabilité RGPD de votre organisation.

Renforcez votre posture de sécurité

Audit, pentest, formation, conseil — une approche sur-mesure adaptée à votre contexte.

Demander un devis [email protected]

Automatiser la vérification des sauvegardes : scripts et alertes

La plupart des organisations ont une stratégie de backup théorique. Mais sans vérification automatisée et régulière, vous ne saurez que la sauvegarde est corrompue ou inexistante qu'au moment où vous en avez le plus besoin : pendant l'incident. Les groupes ransomware le savent : ils testent vos plans de reprise avant vous.

La vérification passive (juste vérifier que le job s'est terminé en succès) ne suffit pas. Vous avez besoin de tests de restauration automatisés — idéalement quotidiens pour les données critiques. Concrètement, cela signifie :

• Restauration automatique dans un environnement isolé : un container ou une VM de test provisionnée automatiquement chaque nuit, qui restaure la dernière sauvegarde et vérifie l'intégrité des données (hash SHA-256 des fichiers critiques, démarrage de services, vérification de cohérence base de données)
• Alertes sur anomalies : tout écart de taille de sauvegarde supérieur à 30% par rapport à la moyenne mobile des 7 derniers jours doit déclencher une alerte — un ransomware qui chiffre progressivement vos fichiers va faire augmenter la taille des fichiers de sauvegarde avant que l'alerte humaine soit déclenchée
• Surveillance des agents de sauvegarde : détection de désactivation des services Veeam, Acronis, Commvault — une règle Sigma ou YARA dans votre SIEM pour tout arrêt non planifié de ces processus
• Immuabilité matérielle ou logicielle : Object Lock S3 en mode compliance (pas governance — les admins ne peuvent pas override), Veeam Hardened Repository sur Linux avec chroot et root désactivé via SSH

Un script de vérification minimal en Python qui s'exécute après chaque backup :

import hashlib, boto3, subprocess
def verify_backup_integrity(bucket, key, expected_sha256):
    s3 = boto3.client('s3')
    obj = s3.get_object(Bucket=bucket, Key=key)
    actual = hashlib.sha256(obj['Body'].read()).hexdigest()
    if actual != expected_sha256:
        send_alert(f"CORRUPTION DÉTECTÉE: {key}")
        return False
    return True

Ce niveau d'automatisation est atteignable en deux sprints pour une équipe de 3 personnes. Le ROI est mesurable : lors des incidents auxquels j'ai répondu, les organisations avec des tests de restauration automatisés ont réduit leur RTO de 72h à 6h en moyenne.

Segmentation réseau et protection des sauvegardes offline

La règle 3-2-1 est devenue insuffisante face aux ransomwares modernes qui persistent pendant 3 à 6 semaines avant de déclencher leur payload. Vos trois copies peuvent toutes être compromises pendant cette fenêtre. La règle actualisée est 3-2-1-1-0 : 3 copies, 2 supports différents, 1 hors site, 1 offline (air-gapped), 0 erreur vérifiée.

La composante offline est non-négociable pour les données critiques. Les options pratiques :

• Bande LTO-9 : toujours la méthode air-gap la plus économique pour de gros volumes — un système de rotation hebdomadaire avec une bande hors site suffit pour la plupart des PME. Le coût d'une librairie LTO-9 entry-level est souvent inférieur au coût d'une semaine d'interruption
• Appliance immuable dédiée : serveur backup physiquement séparé du réseau principal, accessible uniquement depuis un VLAN de management isolé, avec authentification MFA et règle de pare-feu autorisant uniquement les flux de sauvegarde entrants (jamais sortants vers le réseau principal)
• Isolation réseau : le serveur de sauvegarde ne doit jamais être membre du domaine Active Directory — c'est la première chose que compromet un opérateur ransomware qui a un accès domain admin. Authentification locale uniquement, comptes de service dédiés avec privilèges minimaux

La segmentation réseau autour des sauvegardes suit un principe simple : le trafic de sauvegarde doit circuler dans une direction unique. Les agents sur les serveurs de production poussent vers le serveur de sauvegarde — le serveur de sauvegarde ne tire jamais depuis la production. Cette asymétrie rend beaucoup plus difficile l'utilisation des agents comme vecteur de mouvement latéral.

En pratique, lors de mes audits, je trouve systématiquement des serveurs Veeam avec des comptes de service disposant de droits administrateurs locaux sur les 200+ serveurs de l'entreprise. C'est un rêve pour un attaquant qui a compromis le compte de service Veeam : il peut déployer son ransomware sur l'ensemble du parc en quelques secondes via les mêmes mécanismes que la sauvegarde utilise pour fonctionner.

Plan de reprise après ransomware : le document que votre assureur va vous demander

Depuis 2024, les assureurs cyber exigent systématiquement un Plan de Reprise d'Activité testé comme condition d'éligibilité à leur couverture ransomware. "Testé" signifie documenté avec une date, un responsable nommé, et un résultat mesuré. Le tarif moyen d'une prime cyber a baissé de 18% en 2025 pour les organisations avec un PRA documenté — et augmenté de 34% pour celles sans.

Le PRA orienté ransomware doit répondre à trois questions précises :

• RTO (Recovery Time Objective) : combien de temps maximum pour redémarrer chaque service critique ? Segmentez par tier : Tier 1 (services vitaux - 4h), Tier 2 (services importants - 24h), Tier 3 (services secondaires - 72h)
• RPO (Recovery Point Objective) : quelle perte de données est acceptable ? Pour la comptabilité : 15 minutes max. Pour le suivi client : 1 heure. Pour les données analytiques : 24h peut être acceptable
• Dépendances cachées : c'est le point que la plupart des PRA ratent. Votre ERP peut être sauvegardé correctement, mais s'il dépend d'un service d'authentification SSO qui est compromis, vous ne pouvez pas le relancer. Documentez l'ordre précis de démarrage des services

Le format pratique d'un runbook de reprise ransomware :

1. Activation de la cellule de crise (RACI : qui décide, qui fait, qui communique)
2. Isolation des systèmes compromis (liste des actions par type de système)
3. Évaluation du périmètre de compromission (accès aux logs SIEM, timeline des IOC)
4. Activation de l'environnement de reprise (VMs propres, réseau isolé)
5. Restauration tier 1 depuis la dernière sauvegarde propre vérifiée
6. Vérification d'intégrité avant reconnexion réseau
7. Communication interne et externe (selon modèle ANSSI)

Ce document doit être stocké en dehors de votre SI principal — imprimé dans un coffre physique ou dans un référentiel cloud séparé avec accès multi-facteur. Lors d'un ransomware, votre SI sera chiffré, et votre PRA avec lui si vous l'avez stocké dans SharePoint.

Checklist de contrôle mensuel de votre dispositif backup

Voici la checklist que je laisse systématiquement à mes clients après un audit backup. À réaliser chaque mois par le responsable infrastructure :

• ☑ Vérifier que le dernier job de backup a réussi sur 100% des systèmes critiques
• ☑ Tester la restauration d'au moins un système de chaque tier (1, 2, 3) sur un environnement isolé
• ☑ Vérifier que les serveurs Veeam/Acronis ne font pas partie du domaine AD
• ☑ Confirmer que la dernière bande LTO (ou backup offline) est bien en dehors du site principal
• ☑ Vérifier les alertes sur les volumes de backup (±30% par rapport à la semaine précédente)
• ☑ Tester que les comptes de service backup ont des privilèges minimum et que les accès SSH root sont désactivés sur le serveur Hardened Repository
• ☑ Vérifier que le PRA ransomware est accessible hors-SI (copie imprimée ou cloud séparé)
• ☑ Confirmer que les patches de sécurité sont appliqués sur les logiciels de backup et leurs agents

Cette checklist prend 30 minutes par mois à remplir sérieusement. Elle vous économisera des semaines de récupération lors d'un incident réel. La plupart des organisations que j'audite ne font aucune de ces vérifications régulièrement — et le découvrent à leurs dépens lors d'un ransomware.