Ransomware : comment l’université de Maastricht s’est confrontée à Clop

Une autre victime de Clop

La compromission initiale est survenue mi-octobre, par hameçonnage, une époque où le groupe TA505 se faisait remarquer par ses activités prononcées. En France, il lui est notamment attribué l’infection du CHU de Rouen par le rançongiciel Cryptomix Clop. Dans l’e-mail de phishing reçu à l’université de Maastricht se trouvait un lien vers un fichier caché derrière une adresse liée au nom de domaine onedrive-download-en[.]com, identifié le 15 octobre par les équipes de Threat Connect, et enregistré la veille. Celles-ci avaient immédiatement soupçonné le groupe TA505. D’autres domaines sont mentionnés dans le rapport de Fox-IT – et l’on retrouve des éléments publiés par Proofpoint mi-octobre –, dont au moins un qui avait été identifié, mais pas formellement lié aux activités de TA505.

Par la suite, les assaillants se sont déplacés dans le réseau. Le 21 novembre, ils avaient gagné le contrôle complet du système d’information, profitant notamment de vulnérabilités pour lesquelles les correctifs disponibles n’avaient pas été appliqués, en l’occurrence MS17-0104 : deux serveurs sous Windows Server 2003 R2 étaient vulnérables à EternalBlue, de même qu’un troisième sous Windows Server 2012 R2. Le 24 octobre, ils ont commencé à remonter aux contrôleurs de domaine avec l’outil PingCastle. La prise de contrôle a été finalisée le 19 décembre, avec l’aide de l’outil AdFind.

Profitant de ce contrôle, les attaquants ont désactivé les systèmes de protection des hôtes (EPP) en place, signés McAfee, le 23 décembre, afin de pouvoir déployer sereinement la charge de chiffrement. Laquelle a été détonée dans la foulée. La réponse a pu être engagée le lendemain, avec l’aide de Fox-IT, et notamment l’isolation des systèmes affectés. À cette date, le nom du rançongiciel circulait déjà, de même que celui du prestataire appelé à l’aide.

Au total, après compromission des contrôleurs de domaine, et donc, de l’infrastructure Active Directory, les assaillants ont chiffré 267 serveurs. Le sujet d’une éventuelle exfiltration de données n’apparaît pas encore clos à ce stade.

Payer pour gagner du temps

Mais très vite, l’université a annoncé un calendrier agressif, évoquant dès le 28 décembre que les bâtiments seraient ouverts dès le 2 janvier, puis que les processus liés à l’enseignement devaient être à nouveau opérationnels le 6 janvier. En fait, dès le 2 janvier, certains systèmes ont pu être remis graduellement en route. Le 3 janvier, 15 000 étudiants et employés avaient pu changer leurs mots de passe. Et le 7 janvier, les partages réseau étaient à nouveau accessibles depuis les réseaux filaires.

Pour aller aussi vite, la mobilisation a été considérable, avec plus d’une centaine de personnes sur le pont lors de Noël. Mais afin d’éviter de pénaliser notamment les étudiants et les travaux de recherche, la décision – présentée comme réellement lourde et difficile – a été prise de payer la rançon demandée. Après avoir vérifié que les assaillants disposaient d’un outil de déchiffrement fonctionnel, le montant demandé a été réglé le 30 décembre.

Les leçons retirées de cet épisode sont nombreuses et soulignent l’importance d’une approche complète de la cybersécurité, associant utilisateurs et contrôles techniques multiples. La première renvoie sans surprise à la sensibilisation, pour permettre aux utilisateurs de repérer les tentatives de phishing, mais aussi de les signaler. Un premier destinataire du message de hameçonnage avait ainsi vu le piège. Mais un second s’y est hélas fait prendre.

Une protection combinant humain et technique

Sur le volet technique, il y a bien sûr la question de l’application des mises à jour. Mais l’enjeu est considérable : pour l’université de Maastricht, le compte s’établit autour de 100 000 correctifs à appliquer par an, à raison de 1 650 serveurs et plus de 7 300 de postes de travail – dont certains en VDI. À cela s’ajoute l’application généralisée du principe de moindre privilège, mais aussi celle du concept de segmentation réseau – et surtout du domaine. Cela doit permettre de limiter les capacités de déplacement des assaillants et l’impact d’une éventuelle compromission réussie.

Mais pas question d’attendre qu’elle survienne : pour détecter, il faut un service de SOC, pour surveiller le trafic réseau, repérer les signaux faibles. Et d’appeler notamment à la création d’un tel service mutualisé pour le secteur de l’éducation. Mais la détection des signaux faibles doit s’étendre aux hôtes du système d’information. L’université de Maastricht a d’ailleurs récemment annoncé le déploiement de l’EDR de Carbon Black.

Mais l’approche reste incomplète si les moyens sont absents pour rebondir en cas d’incident. En plus des sauvegardes en ligne préexistantes, mais potentiellement exposées au risque de compromission, des sauvegardes hors ligne ont été mises en place – dès le début du mois de janvier.