Il est 12h30. Un vendredi. En supervisant les connexions serveurs, je remarque qu’un accès ne répond plus sur l’écran de supervision. Pas d’alerte automatique. Juste une ligne qui disparaît. J’appelle immédiatement l’administrateur système.

Ce n’est pas une panne. C’est une cyberattaque.

En quelques minutes, la réalité s’impose : un cryptolocker est en train de chiffrer les données du groupe sur l’ensemble des sites — France, Portugal, Roumanie, Suisse. La production est à l’arrêt sur tous les sites simultanément. Et quand nous cherchons les sauvegardes pour déclencher la reprise, nous découvrons qu’elles aussi ont été compromises. Elles étaient connectées au même réseau que les systèmes de production.

Quelques heures plus tard, les attaquants envoient leur demande de rançon.

Nous avons décidé de ne pas payer.

Ce qui a suivi est probablement l’expérience la plus intense de ma carrière de DSI. Je vais vous la raconter dans le détail — la décision de ne pas payer, la gestion de crise, la reconstruction complète du SI, et surtout ce que ça m’a appris. Pas pour faire peur. Mais parce que la plupart des dirigeants de PME pensent que ça n’arrive qu’aux autres.

Le contexte — Un groupe industriel multi-sites, multi-pays

Nous sommes dans un groupe industriel avec des usines réparties sur plusieurs pays. Des dizaines de machines connectées au SI. Un ERP groupe. Des flux de production qui dépendent à 100% de l’informatique. Des équipes en France, au Portugal, en Roumanie et en Suisse.

Ce n’est pas une startup tech. C’est une PME industrielle solide sur son cœur de métier — mais dont la maturité cybersécurité était insuffisante. Quand j’analyse ce qui a permis l’attaque, trois facteurs se cumulent :

  • Un manque d’hygiène informatique sur les accès : mots de passe faibles, comptes partagés entre utilisateurs, accès distants sans authentification multifacteur. C’est par là que les attaquants sont entrés.
  • Un durcissement des règles de cybersécurité insuffisant : pas de segmentation réseau entre les sites, pas d’EDR sur les postes et serveurs, des règles de pare-feu permissives. Une fois à l’intérieur, rien n’a limité la propagation latérale sur l’ensemble du réseau multi-sites.
  • Une dette technique qui a facilité l’attaque : systèmes non patchés depuis des mois, versions de Windows Server abandonnées par Microsoft, applications métiers sur des environnements obsolètes. Des vulnérabilités connues, documentées — et non corrigées. En savoir plus sur la dette technique en PME.

L’attaque n’est pas tombée du ciel. Elle a exploité des failles qui existaient depuis longtemps — et que personne n’avait eu le mandat ni les ressources pour corriger.

La mécanique de l’attaque

Un cryptolocker ne frappe pas en une nuit. Les attaquants étaient dans le réseau depuis plusieurs jours — peut-être plusieurs semaines. Ils avaient cartographié le SI, identifié les serveurs critiques, localisé les sauvegardes, escaladé les privilèges jusqu’aux comptes administrateurs. Quand ils ont déclenché le chiffrement, ils l’ont fait de manière coordonnée sur l’ensemble des sites simultanément.

Le chiffrement s’est propagé à une vitesse que nous n’avions pas anticipée. En moins de deux heures, la quasi-totalité des données accessibles sur le réseau était chiffrée — fichiers de production, base ERP, données comptables, documents partagés sur tous les sites dans tous les pays.

Et là, le coup de grâce : les sauvegardes étaient connectées au même réseau que les systèmes de production. Les attaquants les avaient identifiées et chiffrées avant nous. Nous n’avions rien pour restaurer.

La décision de ne pas payer la rançon

Quelques heures après le début de l’attaque, les attaquants ont envoyé leur demande de rançon. Le montant était significatif. La pression était réelle — production arrêtée, clients en attente, équipes mobilisées sur tous les sites.

La décision a été prise rapidement, en concertation avec la direction générale, l’assureur cyber et les autorités : nous ne paierons pas.

Cette décision est difficile à prendre sous pression. Voici les raisons qui l’ont motivée :

  • Payer ne garantit pas la restauration. Les attaquants peuvent prendre l’argent et ne jamais fournir la clé de déchiffrement. Ou fournir une clé partielle. Ou une clé qui ne fonctionne que sur certains systèmes. Nous aurions payé pour rien.
  • Payer finance les attaques suivantes. Les groupes de ransomware réinvestissent les rançons dans le développement de nouvelles attaques. En payant, on finance l’organisation qui vient de nous attaquer — et qui attaquera d’autres PME demain.
  • Payer fait de vous une cible prioritaire. Les victimes qui ont payé sont répertoriées comme « payeuses » dans les bases de données des groupes criminels. Le risque d’une deuxième attaque — sur la même organisation ou sur ses filiales — est significativement plus élevé.
  • La recommandation des autorités est unanime. L’ANSSI, Cybermalveillance.gouv.fr et les forces de l’ordre déconseillent fermement le paiement. Suivre cette recommandation était aussi une question d’exemplarité et de cohérence avec nos engagements.

Cette décision a eu un coût — en temps, en énergie, en ressources mobilisées pour la reconstruction. Mais elle était la bonne. Et elle a orienté toute notre stratégie de sortie de crise : puisque nous ne paierions pas, il fallait reconstruire. Entièrement. Correctement.

La gestion de crise — Un concours de forces

La gestion d’une cyberattaque de cette ampleur ne se gère pas seul. Ce que j’ai organisé dans les premières heures, c’est la mobilisation de plusieurs équipes aux compétences complémentaires — chacune indispensable.

L’équipe technique et les prestataires spécialisés en cybersécurité

Isolation immédiate des segments réseau compromis site par site. Coupure des accès distants. Déconnexion physique des équipements encore sains pour les préserver. Analyse forensique pour identifier le vecteur d’entrée, cartographier les systèmes atteints et documenter les preuves avant toute intervention.

Cette phase technique nécessite des compétences pointues en forensique et réponse à incident que peu de PME ont en interne. Nous avons fait appel à des prestataires spécialisés dès les premières heures. Leur intervention a permis d’identifier précisément comment les attaquants étaient entrés, ce qu’ils avaient fait dans le réseau et quels systèmes étaient réellement compromis — information essentielle pour la reconstruction.

L’assurance cyber

Le groupe disposait d’une assurance cyber. Ce point a été déterminant dans notre capacité à gérer la crise. L’assureur a activé immédiatement sa cellule de crise — avec des experts techniques, juridiques et de communication de crise. Ils ont coordonné les prestataires spécialisés et pris en charge une partie significative des coûts de remédiation et de reconstruction.

Ce que j’ai appris : une assurance cyber n’est utile que si elle est activée immédiatement et si les conditions de couverture sont connues avant l’incident. Vérifiez vos conditions générales — certains assureurs exigent des prérequis techniques (MFA, sauvegardes isolées, EDR) dont l’absence peut invalider la couverture au moment du sinistre.

Les forces de l’ordre

Dépôt de plainte dès les premières heures. Notification à la CNIL pour les données personnelles potentiellement compromises — obligation légale dans les 72 heures. Signalement sur Cybermalveillance.gouv.fr.

Ces démarches ne sont pas optionnelles. Elles ouvrent des droits, permettent l’accès à des ressources spécialisées et constituent le dossier nécessaire pour l’assurance. Les enquêteurs ont également contribué à l’identification du groupe attaquant et des outils utilisés — informations précieuses pour adapter notre remédiation et éviter une récidive.

Les sociétés spécialisées en récupération de données

C’est la partie la moins connue du grand public — et l’une des plus déterminantes dans notre sortie de crise. Les sauvegardes réseau étant compromises, nous avons fait appel à des sociétés spécialisées dans la récupération de données sur disques durs physiques.

Ces sociétés travaillent en salle blanche sur les supports physiques — disques durs, NAS, serveurs — pour tenter de récupérer des données chiffrées ou partiellement endommagées que les outils logiciels ne peuvent pas atteindre. Le processus est long, techniquement complexe et coûteux. Les résultats ne sont jamais garantis.

Dans notre cas, nous avons réussi à récupérer des données partielles sur plusieurs supports — notamment des données de production et des historiques comptables. Ces données récupérées ont été intégrées progressivement dans le SI reconstruit, réduisant significativement la durée d’arrêt et les pertes définitives.

Sans ces sociétés spécialisées, certaines données auraient été définitivement perdues. Leur intervention, combinée aux sauvegardes partielles retrouvées sur des supports non connectés au réseau au moment de l’attaque, a permis de limiter l’impact à long terme sur l’activité.

La reconstruction complète du SI

La décision de ne pas payer impliquait une conséquence directe : nous devions reconstruire le SI de zéro. Pas restaurer — reconstruire.

Reconstruire sur un environnement potentiellement compromis, c’est se réinfecter. Chaque composant devait être réinstallé depuis des sources saines, vérifiées, isolées. La tentation de « remettre en route vite » a été écartée dès le début — au prix d’une durée d’arrêt plus longue, mais d’une remise en service définitivement assainie.

Concrètement, la reconstruction a couvert :

  • Effacement complet et réinstallation de tous les serveurs depuis des images saines — sur chaque site, dans chaque pays.
  • Reconstruction de l’infrastructure réseau avec une nouvelle architecture segmentée — pas de réinstallation à l’identique de ce qui existait avant l’attaque.
  • Redéploiement de l’ERP et des applications métiers depuis les sources, avec vérification de l’intégrité de chaque composant.
  • Réintégration progressive des données récupérées — vérifiées et validées avant d’être réintégrées dans les systèmes reconstruits.
  • Recréation de tous les comptes utilisateurs avec de nouveaux identifiants — les anciens comptes étaient potentiellement compromis.
  • Déploiement simultané des nouvelles mesures de sécurité — EDR, MFA, segmentation — intégrées dès la reconstruction, pas ajoutées après.

Cette reconstruction a mobilisé des équipes techniques pendant plusieurs semaines, coordonnées site par site avec des remises en service progressives pour limiter l’impact sur la production. La communication avec les clients, fournisseurs et partenaires a été maintenue tout au long du processus — avec des points réguliers sur l’avancement et les délais de reprise confirmés.

Ce qu’on a mis en place après la crise

La reconstruction n’était pas qu’une remise en route — c’était l’opportunité de corriger ce qui avait permis l’attaque. Voici ce qui a été déployé :

  • EDR SentinelOne sur l’ensemble des postes et serveurs de tous les sites — détection et réponse aux menaces en temps réel.
  • MFA généralisé sur tous les accès distants et comptes à privilèges — sans exception, sans dérogation.
  • Segmentation réseau via Fortigate Security Fabric — isolation des zones (production, bureautique, administration) et des sites entre eux.
  • Plan de sauvegarde revu avec règle 3-2-1 : sauvegardes locales chiffrées, copies déportées sur site secondaire, sauvegarde immuable dans un cloud isolé du réseau de production. Tests de restauration documentés et planifiés tous les trimestres.
  • PCA/PRA réécrit et testé en conditions réelles — procédures documentées, responsables désignés sur chaque site, délais de reprise mesurés.
  • Plan de gestion des vulnérabilités : mises à jour appliquées dans les 30 jours suivant leur publication, inventaire permanent des versions en production.
  • Simulations phishing régulières et sensibilisation de l’ensemble des collaborateurs — le facteur humain reste le premier vecteur d’entrée.

Ce groupe est aujourd’hui infiniment plus résilient qu’il ne l’était. Et surtout, ses équipes savent quoi faire si ça se reproduit — parce qu’elles l’ont appris dans la douleur, et parce que les procédures existent maintenant pour ne pas réimprovisser.

Les leçons que personne ne veut entendre avant la crise

Les sauvegardes connectées au réseau ne sont pas des sauvegardes. Une sauvegarde accessible depuis le réseau de production sera chiffrée en même temps que le reste. La règle 3-2-1 est non négociable — 3 copies, 2 supports différents, 1 hors ligne ou dans un environnement totalement isolé.

La dette technique est un vecteur d’attaque documenté. Les attaquants n’exploitent pas des failles inconnues — ils exploitent des vulnérabilités corrigées par les éditeurs mais non appliquées. Un système patché est infiniment plus résistant qu’un système performant mais obsolète.

Le MFA n’est pas une option. Dans les deux incidents que j’ai gérés, le vecteur d’entrée initial était lié à des accès non protégés par authentification multifacteur. Un attaquant qui récupère un identifiant et un mot de passe ne peut rien faire face au MFA. Sans MFA, il est à l’intérieur du réseau en quelques minutes.

La segmentation réseau limite les dégâts. Sur un réseau plat non segmenté, un cryptolocker se propage sans obstacle à tous les sites. Une architecture segmentée n’empêche pas l’entrée mais confine l’incident à une zone — évitant la propagation multi-sites que nous avons vécue.

La cyber n’est pas un sujet IT — c’est un sujet de direction générale. Le DSI peut alerter, recommander, mettre en place des outils. Mais c’est le DG qui décide du niveau de risque acceptable et du budget alloué. Dans ce groupe, les alertes existaient avant l’incident. Les ressources pour y répondre n’avaient pas été allouées.

5 questions à vous poser cette semaine

  1. Avez-vous un MFA sur vos accès distants et vos comptes administrateurs ? Si non, c’est votre exposition la plus immédiate.
  2. Vos sauvegardes sont-elles physiquement ou logiquement isolées du réseau de production ? Une sauvegarde connectée en permanence ne vous protégera pas d’un cryptolocker.
  3. Vos sauvegardes ont-elles été testées en conditions réelles dans les 12 derniers mois ? Une sauvegarde non testée est une sauvegarde dont vous ignorez si elle fonctionne.
  4. Savez-vous qui appeler en premier si votre SI tombe un vendredi à 12h30 ? Cette réponse doit exister avant la crise — pas pendant.
  5. Vos systèmes sont-ils à jour — serveurs, postes, applications ? Les systèmes non patchés sont des portes d’entrée documentées que les attaquants exploitent en priorité.

Si vous répondez non à 2 de ces 5 questions, votre exposition est réelle et immédiate.

Vous voulez évaluer votre exposition réelle au risque cyber ?

Un premier échange de 30 minutes suffit à identifier les priorités. Sans jargon, sans engagement.

Prendre rendez-vous — 30 min gratuits

Questions fréquentes — Cryptolocker et ransomware en PME

Faut-il payer la rançon ?
Non. Nous avons choisi de ne pas payer — et c’était la bonne décision. Payer ne garantit pas la restauration des données. Cela finance des organisations criminelles et augmente le risque d’une deuxième attaque sur votre organisation. La recommandation des autorités (ANSSI, Cybermalveillance.gouv.fr) est unanime : ne pas payer. Cette décision est difficile à prendre sous pression, avec la production à l’arrêt — mais elle s’impose sur le long terme.

Faut-il forcément reconstruire le SI de zéro après un cryptolocker ?
Pas toujours — cela dépend de l’ampleur de l’attaque et de la qualité des sauvegardes disponibles. Dans notre cas, la combinaison d’un réseau non segmenté, de sauvegardes compromises et d’un périmètre multi-pays a rendu la reconstruction complète inévitable. Si vous disposez de sauvegardes isolées et testées, la restauration peut suffire. C’est précisément pour ça que les sauvegardes hors ligne sont non négociables.

Mon assurance cyber couvre-t-elle un incident ransomware ?
Potentiellement — mais vérifiez les conditions avant d’en avoir besoin. Certains assureurs imposent des prérequis techniques (MFA, sauvegardes isolées, EDR) dont l’absence peut invalider la couverture au moment du sinistre. L’assurance cyber a été déterminante dans notre capacité à gérer la crise — mais uniquement parce qu’elle existait et que les conditions étaient remplies.

Quelle est la première chose à faire si je détecte une attaque en cours ?
Isoler immédiatement les systèmes compromis — couper les connexions réseau, pas éteindre les machines (l’extinction peut détruire des preuves forensiques utiles pour les experts et les assureurs). Appeler votre prestataire de sécurité ou l’ANSSI. Notifier votre assureur cyber. Déposer plainte. Et documenter chaque action dès le début — pour les autorités, pour les assureurs, pour le bilan post-incident.

Prendre rendez-vous