Le rançongiciel se prépare avec une restauration, pas une promesse
En mai, Colonial Pipeline a interrompu ses opérations. En juillet, l’attaque contre Kaseya a atteint plusieurs organisations par un outil de gestion TI. Les chemins diffèrent, mais le constat est le même : une intrusion numérique peut arrêter des opérations très physiques, et un outil d’administration puissant devient un multiplicateur lorsqu’il est compromis.
Le chiffrement visible est souvent la fin de l’attaque, pas le début. Un opérateur obtient un accès par hameçonnage, mot de passe réutilisé, service exposé ou vulnérabilité. Il élève ses privilèges, découvre l’annuaire, vole d’autres identifiants, se déplace vers les serveurs et peut exfiltrer des données. Il cherche ensuite les sauvegardes et outils de sécurité avant de déployer le rançongiciel à grande échelle.
accès initial → privilèges → reconnaissance → mouvement latéral
→ exfiltration → sabotage des sauvegardes → chiffrement
Les protections doivent couper cette chaîne à plusieurs endroits :
- correctifs et réduction des services exposés;
- authentification multifacteur, surtout pour VPN et administration;
- comptes administrateurs distincts et privilèges juste à temps;
- segmentation entre postes, serveurs, sauvegardes et opérations;
- EDR et journaux centralisés pour détecter les comportements;
- limitation des outils de déploiement à des paquets signés et contrôlés;
- copies isolées ou immuables avec identités séparées;
- exercice de détection, confinement et restauration.
Une segmentation utile contrôle les flux réels. Le poste comptable n’a pas besoin d’ouvrir SMB vers chaque serveur. Le système de gestion ne devrait pas exécuter n’importe quelle commande partout avec un seul compte permanent. Le firewall et les droits limitent la portée, tandis que des alertes repèrent une création massive de fichiers chiffrés, la suppression de snapshots ou une connexion administrative inhabituelle.
Restaurer dans un environnement encore hostile
Une sauvegarde reliée aux mêmes identités peut être supprimée ou chiffrée. Une copie immuable refuse la modification pendant une période; une copie hors ligne n’est pas joignable depuis le réseau courant. Il faut quand même vérifier qu’elles contiennent les bases, fichiers, configurations, clés et versions nécessaires.
Je fixerais un RPO et un RTO par service. Une paie peut accepter quelques heures de données à ressaisir, pas trois semaines. Restaurer un téraoctet à 100 Mo/s prend près de trois heures dans des conditions idéales, avant validation et redémarrage. Le débit réel, les dépendances et le scan de sécurité allongent ce temps.
L’ordre de reprise commence par un socle propre :
canal de communication externe
→ identité/DNS de récupération
→ réseau et postes d'administration propres
→ sauvegardes vérifiées
→ services critiques et leurs bases
→ intégrations et postes utilisateurs
Remettre un serveur restauré dans un domaine encore contrôlé par l’attaquant le compromet de nouveau. Les comptes, jetons, certificats et secrets potentiellement volés doivent être révoqués ou remplacés. L’équipe conserve les preuves avant de nettoyer et définit qui peut déclarer un environnement fiable.
Le plan prévoit un mode manuel. Quels bons de commande peut-on traiter sur papier? Comment joindre les employés sans courriel? Qui autorise l’isolement d’un site? Les coordonnées et procédures vivent aussi hors du réseau principal. Une restauration réussie doit remettre les permissions correctes et permettre une transaction métier test, pas seulement afficher un écran de connexion.
Je préfère qu’un exercice trouve dix trous. Je choisirais un service, supposerais Active Directory et le courriel indisponibles, restaurerais sur un réseau isolé puis mesurerais chaque étape. Avant d’acheter un autre produit dans l’urgence, je veux savoir qui peut couper la propagation, où est la copie que l’attaquant ne peut pas modifier et combien de temps il faut pour produire une première opération fiable.