Retour d’expérience : comment l’université technologique d’Eindhoven a fait face à une cyberattaque majeure

Comment avez-vous découvert l’attaque ? Quels en ont été les premiers signes ?

Nous l’avons d’abord détectée grâce au système de surveillance de sécurité de l’Université, qui nous a alertés de l’installation d’outils d’accès à distance sur les contrôleurs de domaine. Cela s’est produit vers 21h30 un samedi soir. Il était évident que ce n’était pas une modification planifiée par notre équipe — c’est à ce moment-là que nous avons su que quelque chose n’allait pas.

Dès que l’alerte est arrivée, notre équipe d’experts a immédiatement commencé à travailler pour remédier à la situation. Il est rapidement devenu évident que les cybercriminels avaient obtenu des accès à privilèges élevés. Je pense qu’en moins d’une heure, nous avons réalisé qu’il fallait déconnecter le réseau d’Internet.
Nous avons continué à lutter contre les attaquants pendant environ deux heures après les premières alertes. Durant cette période, il nous a fallu agir de manière décisive pour reprendre le contrôle. Nous avons pris la décision de couper complètement le réseau à 1h du matin, dimanche. Ainsi, il s’est écoulé environ trois heures et demie entre la première alerte et la déconnexion effective.

Une fois l’ampleur de l’attaque découverte, quelles ont été vos premières priorités, tant du point de vue technique que de la gestion de crise ?

Du point de vue technique, dès qu’on découvre ce type d’attaque, on cherche à évaluer son étendue et à identifier rapidement les mesures pour limiter les dégâts. En quelques heures, nous avons compris que l’attaque était trop importante pour être contenue tout en restant en ligne. Les attaquants avaient compromis nos contrôleurs de domaine, ce qui signifie qu’ils avaient accès à tout notre environnement.
Nous étions encore en lutte active avec eux durant cette phase. Nous avons compris que si nous continuions ainsi, nous ne pourrions pas reprendre le dessus. C’est pourquoi nous avons finalement décidé de déconnecter le réseau. Bien sûr, il fallait aussi s’assurer que nous gardions un accès interne pour pouvoir commencer les travaux de restauration. Pour nous, reprendre le contrôle signifiait une coupure complète d’Internet.

Du point de vue de la gestion de crise, dès que la gravité de la situation a été claire et que le plus haut niveau de mobilisation s’est imposé, j’ai été informé en tant que RSSI dans la première heure. Le service informatique a été pleinement mobilisé durant la nuit. Pendant que nous déconnections l’université du réseau, nous savions que nous avions affaire à un incident majeur. Nous avons immédiatement commencé à préparer la convocation de notre cellule centrale de crise pour dimanche matin.
En résumé, il y avait deux responsabilités parallèles : la réponse technique, pour reprendre la maîtrise de la situation, et la gestion de crise, pour évaluer l’impact global sur l’université et coordonner la réponse. Nous savions que les étudiants devaient préparer des examens prévus la semaine suivante. Il fallait donc qu’ils comprennent qu’ils n’auraient pas accès au réseau. Nous savions aussi que sans communication claire, il y aurait beaucoup de spéculations.

Comment avez-vous organisé la cellule de crise ? Qui y a participé, et comment avez-vous coordonné les partenaires internes et externes ?

Sur le plan technique, nous avions un partenaire externe qui nous a aidés pour l’analyse et la réponse. Ils sont arrivés sur le campus à 3h du matin dimanche et ont été intégrés avec nous tout au long de l’incident.
Notre organisation de crise fonctionne à plusieurs niveaux. Dans le département informatique, nous avons une équipe de résolution de crise qui gère la partie technique. Cette équipe coordonne la résolution technique, tandis que d’autres équipes IT se concentrent sur des activités de restauration spécifiques. Une fois que l’on sait ce qui doit être restauré et remis en service, toutes ces équipes se mobilisent. Ensuite, nous avons une équipe de gestion de crise qui coordonne la crise à l’échelle du département IT et communique avec la cellule centrale de crise.

La cellule centrale de crise au niveau de l’université gère tous les autres domaines impactés — tout ce qui concerne les plannings d’examens, la communication externe, etc. Elle coordonne la réponse organisationnelle plus large, au-delà des seuls aspects techniques.

Pour la coordination, nous avons maintenu des échanges réguliers entre toutes ces équipes, avec des rôles et responsabilités bien définis. J’ai personnellement tenu informés mes homologues RSSI des autres universités néerlandaises. Nous avons aussi collaboré étroitement avec SURF — l’organisation collaborative pour l’ICT dans l’éducation et la recherche aux Pays-Bas — en les tenant au courant des aspects techniques de l’attaque.
Au niveau du conseil d’administration, nous avons informé le Ministère de l’Éducation néerlandais et les autorités d’inspection de l’éducation. La communication avec toutes les agences gouvernementales concernées a été maintenue tout au long de l’incident.

Pouvez-vous nous parler de votre stratégie de communication durant la crise ?

Notre cellule centrale de crise s’est réunie à 9h dimanche matin. À partir de midi, nous avons commencé une cadence régulière de communications. Chaque jour, en fin d’après-midi, nous fournissions une mise à jour sur l’état des choses et ce que les gens pouvaient attendre pour le lendemain — s’ils pouvaient étudier ou travailler normalement.
Dimanche et lundi, nous avons communiqué qu’il n’y aurait pas de réseau ni de services le lendemain. Mardi, nous avons annoncé qu’aucune connectivité réseau ne serait disponible pendant au moins une semaine. L’essentiel était d’adresser à tous des messages clairs et cohérents. Nous ne voulions pas que les gens spéculent en permanence ou soient anxieux à l’idée de pouvoir ou non étudier ou travailler le lendemain. En donnant des mises à jour quotidiennes à heure fixe, nous avons contribué à réduire l’incertitude.
Nous avons finalement décidé de reporter tous les examens d’une semaine, afin de donner à chacun le temps nécessaire pour se préparer une fois les systèmes restaurés.

Quel a été le vecteur d’attaque ? Comment les cybercriminels ont-ils accédé au réseau et quelles tactiques ont-ils utilisées ?

Les attaquants ont utilisé essentiellement trois techniques principales pour obtenir l’accès initial.
Premièrement, ils ont utilisé des identifiants trouvés sur le dark web — des noms d’utilisateur et mots de passe d’étudiants et employés compromis lors de fuites précédentes. Ces utilisateurs avaient été identifiés comme ayant des identifiants divulgués et avaient été invités à changer leurs mots de passe, mais ils avaient simplement réutilisé les mêmes mots de passe, car une mauvaise configuration permettait cela.

Deuxièmement, ils ont utilisé ces identifiants pour se connecter à notre VPN, qui à ce moment-là n’était pas encore protégé par une authentification multi-facteurs (MFA). La mise en place de la MFA était prévue pour cette période, avant l’été.
Une fois sur le réseau, ils ont procédé à une reconnaissance pour trouver des environnements où ils pouvaient élever leurs privilèges. Ils ont exploité des protocoles hérités que nous devions maintenir pour assurer la compatibilité avec de vieux logiciels. Grâce à ces protocoles, ils ont pu obtenir des accès administratifs aux systèmes critiques.
Nous avons découvert toute la chaîne d’attaque lundi, après avoir arrêté les systèmes et mené une enquête approfondie. C’est à ce moment que nous avons compris précisément comment ils avaient compromis notre environnement.

Après avoir arrêté les systèmes, quels services avez-vous priorisés pour la restauration ? Quelle a été votre stratégie de reprise ?

Nous avons pu restaurer un point de sauvegarde datant du samedi matin. Nous avons dû vérifier soigneusement que nos sauvegardes étaient saines — nous avons confirmé que la sauvegarde du samedi matin avait été effectuée avant toute compromission, tandis que celles de dimanche et lundi étaient potentiellement infectées.
Nous avons utilisé cette sauvegarde propre du samedi pour restaurer notre environnement de contrôleurs de domaine. Mais avant de remettre quoi que ce soit en marche, nous avons dû garantir que tout était correctement sécurisé.
Au total, en plus des contrôleurs de domaine, 14 serveurs ont dû être entièrement reconstruits et restaurés. Sur environ 77 serveurs ayant montré une activité suspecte, la plupart n’avaient connu que des tentatives de connexion, sans autres actions malveillantes. Nous avons dû tous les scanner minutieusement pour nous assurer qu’ils étaient propres avant de les remettre en ligne.

Quelles mesures de sécurité avez-vous mises en place pour renforcer la résilience face à de futures attaques ?

Nous avons identifié et corrigé plusieurs vulnérabilités. D’abord, nous avons rectifié la mauvaise configuration de notre procédure de réinitialisation des mots de passe. Désormais, lorsque quelqu’un change son mot de passe, le système vérifie activement qu’il ne réutilise pas un ancien mot de passe potentiellement compromis.
Ensuite, nous avons déployé complètement l’authentification multi-facteurs sur notre solution VPN. Nous avons aussi durci nos systèmes pour empêcher autant que possible l’usage de protocoles d’authentification hérités.
Par ailleurs, nous avons accéléré la mise en œuvre de plusieurs autres mesures de sécurité déjà prévues. Cet incident nous a permis d’accélérer ces améliorations avec une urgence plus forte que prévue initialement.

Quels conseils donneriez-vous aux RSSI d’autres universités, à partir de votre expérience ?

Je pense qu’il y a deux conseils principaux.
Premièrement, soyez très prudents avec les systèmes et protocoles hérités sur votre réseau. Oui, vous pouvez en avoir besoin pour la compatibilité avec des systèmes anciens — nous en avons eu. Mais rétrospectivement, nous aurions dû mettre en place de meilleurs contrôles compensatoires.
Deuxièmement, et c’est essentiel : exercez régulièrement votre organisation de gestion de crise cyber. Faites des exercices à tous les niveaux — de l’équipe technique à l’équipe de gestion de crise, jusqu’à la direction centrale de crise. Assurez-vous que chacun connaît clairement ses responsabilités et les procédures d’escalade. Quand un incident survient réellement, ces exercices font une énorme différence.
Les entraînements réguliers nous ont beaucoup aidés, car tout le monde savait quoi faire. Chacun connaissait ses responsabilités, qui présidait quelle réunion, et comment se déroulait le processus. Même sous une pression extrême, les rôles étaient clairs parce que nous avions pratiqué.
Prenez ces exercices au sérieux, même s’il s’agit « juste d’un exercice ». Vous apprenez à gérer la pression, à prendre des décisions sans toutes les informations, et à travailler efficacement quand le temps est compté.

Y a-t-il autre chose que vous aimeriez ajouter ?

Peut-être une autre chose qui, selon moi, a bien fonctionné : durant la crise, nous avons été très attentifs à l’aspect humain. Nous avons mis l’accent sur le bien-être des personnes qui travaillaient à résoudre la crise, pour s’assurer qu’elles allaient bien et ne s’effondraient pas sous la pression.
À partir de dimanche, lorsque nous avions repris le contrôle, nous avons pu prioriser cet aspect. D’un point de vue personnel, nous nous sommes assurés que les équipes prenaient le temps de se reposer durant la crise. Parce qu’au final, les personnes qui font ce travail ne peuvent bien performer que si elles se reposent.