Cas typique : PME touchée par un rançongiciel, les 48 premières heures qui changent tout

Le scénario typique ressemble rarement à une attaque spectaculaire. C'est plutôt une PME ou une ETI avec 150 à 500 utilisateurs, un Active Directory installé depuis longtemps, quelques serveurs Windows critiques, un ERP, des partages SMB, Microsoft 365, un VPN pour les prestataires et des sauvegardes qui existent, mais dont la restauration complète n'a pas toujours été testée.

La direction pense souvent être couverte parce qu'un antivirus, un pare-feu et un outil de sauvegarde sont en place. Sur le terrain, le risque se cache plutôt dans les détails : un compte prestataire encore actif, une MFA absente sur le VPN, des administrateurs trop nombreux, un NAS de sauvegarde joint au domaine ou des journaux conservés trop peu longtemps.

Un cas très courant commence par un identifiant valide. Le mot de passe a pu être récupéré via phishing, réutilisation sur un service compromis ou poste personnel infecté. Si l'accès VPN n'impose pas de MFA, l'attaquant entre sans bruit particulier, souvent le soir ou le week-end.

Une fois dans le réseau, l'attaquant cherche les partages, les serveurs d'administration, les sauvegardes et les comptes à privilèges. Il peut désactiver des protections avec un compte admin, supprimer les copies instantanées Windows, déposer un outil de chiffrement et lancer l'exécution sur plusieurs machines via GPO, PsExec, tâche planifiée ou outil d'administration déjà présent.

Le réflexe naturel est de redémarrer les serveurs, formater des postes ou tout couper sans ordre. C'est compréhensible, mais cela peut effacer des traces utiles ou rendre la reprise plus lente. La priorité est de nommer une cellule courte, figer les actions non essentielles et isoler ce qui propage encore.

Les premiers éléments à préserver sont simples : horodatage des alertes, note de rançon, postes ou serveurs témoins, journaux firewall/VPN, événements AD, logs EDR, événements Microsoft 365/Entra ID, liste des comptes suspects et état des sauvegardes. Même si l'analyse complète vient après, ces preuves permettent de comprendre le point d'entrée et d'éviter de restaurer dans un environnement encore compromis.

Si l'identité reste compromise, la restauration devient fragile. Beaucoup de reprises échouent parce qu'un ancien compte admin, un compte de service ou un accès prestataire permet encore à l'attaquant de revenir. Le travail consiste à réduire la surface d'accès avant de remettre des services en ligne.

Concrètement, il faut désactiver les comptes suspects, réinitialiser les mots de passe des comptes privilégiés, vérifier les groupes sensibles, contrôler les GPO récentes, imposer ou renforcer la MFA sur les accès distants, revoir les comptes de service critiques et documenter les dérogations. Ce n'est pas encore un durcissement parfait : c'est le minimum viable pour restaurer avec moins de risque.

Restaurer ce qui est le plus visible n'est pas toujours ce qui sauve l'activité. L'ordre utile part du métier : facturation, production, logistique, support client, paie, messagerie ou accès aux dossiers critiques. Ensuite seulement, on remonte les dépendances techniques : identité, DNS, DHCP, certificats, stockage, bases de données, applicatifs et postes nécessaires.

La question clé n'est pas seulement 'avons-nous une sauvegarde ?'. C'est 'la sauvegarde est-elle saine, isolée, restaurable, compatible avec les dépendances actuelles et validée par le métier ?'. Un test de restauration ciblé, même imparfait, donne plus de vérité qu'un tableau indiquant que toutes les sauvegardes sont vertes.

Le deuxième jour est souvent le moment le plus délicat : la pression métier augmente, mais la remise en ligne trop rapide peut relancer l'incident. Les services restaurés doivent revenir par étapes, avec supervision renforcée, filtrage réseau, comptes propres, EDR actif, journaux conservés et règles temporaires documentées.

Les décisions doivent rester lisibles : ce que l'on remet en ligne, pourquoi, avec quel risque résiduel, quelle surveillance et qui valide. Cela évite les remises en service implicites où chacun rallume son périmètre sans vision d'ensemble.

Dans un audit découverte, ce cas sert de base très concrète : où l'attaque entrerait-elle chez vous, quels comptes permettraient de se déplacer, quelles sauvegardes survivraient, quel service reprendrait en premier et quelles preuves seraient disponibles dans les premières heures ?

La sortie attendue n'est pas un document théorique. C'est une liste priorisée : fermer les accès exposés, imposer la MFA sur les accès sensibles, tester une restauration critique, isoler les sauvegardes, nettoyer les comptes privilégiés, préparer un annuaire hors SI, clarifier la communication et décider qui arbitre en crise.