La victime : une entreprise internationale employant 6 000 personnes. Les faits : une attaque de “crypto-locking” sur l’ensemble des infrastructures Windows, qui présentaient des vulnérabilités connues. Le coupable ? Un ransomware de la famille Petya. L’attaque portait à la fois sur les postes de travail, mais aussi sur les environnements serveurs Windows de type Active Directory¹ (abrégé “AD” par la suite), serveurs de messagerie, serveurs SharePoint, contrôleurs de domaine… Elle a consisté à introduire son vecteur dans les systèmes de l’entreprise, avec la particularité d’être résident silencieux – point important, comme nous le verrons plus tard –, ce qui permettait de la déclencher ou de l’activer à un instant voulu. 

Conséquence immédiate : 6 000 postes de travail crypto-lockés dans le monde entier, la même seconde, présentant un écran rose : « Vous avez été crypto-locké. Pour obtenir la clé, veuillez verser une rançon sous forme de bitcoins à telle adresse, sinon bon courage ! ». Une bombe à retardement s’était déclenchée.

Cela ne s’est bien sûr pas arrêté là : les serveurs Windows techniques et applicatifs qui, eux aussi, avaient été mal configurés, mal patchés², mal durcis, ont pour partie aussi été crypto-lockés, en particulier Active Directory, Messagerie et quelques autres. Au même instant, l’ensemble des postes de travail et des moyens de connexion de l’entreprise se retrouvent down. Voilà l’attaque et ses conséquences directes.

Pour réagir, encore faut-il en avoir les moyens

Et voici la réaction. La première décision à prendre, c’est : faut-il payer la rançon ? La politique usuelle des grandes entreprises étant de ne pas payer, l’alternative se résume à se lancer dans un exercice de reconstruction ou de redémarrage. Premier réflexe : “Il va falloir remastériser³ les postes de travail”. Pour ce faire, vous devez disposer de l’Active Directory et de la base image, étant acquis que vous détenez toujours le système Windows central qui permet de construire des postes et de télédistribuer (à la fois les images, mais aussi la configuration, le paramétrage, les droits, les habilitations…). Mais Active Directory est lui aussi chiffré ! Il faut donc le restaurer en premier. Mais la bombe était déjà là au moment où la sauvegarde a été opérée, une, deux ou trois semaines auparavant. Et donc, à l’instant de la restauration et de l’activation du serveur, le malware se lance et rechiffre les fichiers. La pratique n’étant pas de conserver des sauvegardes de l’AD sur une longue période (les sauvegardes cycliques portent sur des périodes relativement courtes, typiquement en jours ou en semaines), il faut se rendre à l’évidence : comme l’attaque était silencieuse depuis plusieurs semaines (voire deux ou trois mois), on ne dispose plus de sauvegarde de l’AD suffisamment ancienne non compromise. De toute façon, le serveur de sauvegarde s’était fait chiffrer lui aussi…

Il a donc fallu que l’entreprise se lance dans une construction ex nihilo des environnements, ce qui signifie repartir de serveurs tout neufs. Bien sûr, le matériel peut être réutilisé, mais à condition de détruire tout, à l’ancienne, si l’on ose dire (on met le CD et on tape “C : install”, ou pour les plus âgés d’entre nous “A : install” à l’ère des disquettes).

Avec l’aide d’experts techniques, l’entreprise a dû reconstituer complètement l’environnement central Microsoft (appelons-le comme ça), constitué de l’AD, du DNS, de la messagerie Exchange, puis des points de distribution… ce qui a pris un temps significatif. Puis de reconstituer, une fois cela réalisé, les données utilisateurs, avec des données soit récupérées, soit recomposées manuellement. Tout cela constitue un prérequis à la création du premier poste.

En parallèle, il a fallu recréer un master propre avec les bonnes pratiques, les bons niveaux, sécurité, paramétrages… pour que l’entreprise puisse remastériser ses 6 000 postes de travail sur des bancs de remastérisation – ce qui prend quelques jours, ou plutôt quelques semaines – pour progressivement redistribuer des postes, en priorisant les fonctions les plus critiques, les plus vitales de l’entreprise, et en élargissant progressivement jusqu’à rétablir les services essentiels, puis les services applicatifs additionnels qui eux aussi avaient été touchés pour partie. 

L’ensemble aura duré plusieurs semaines. C’est une des très grosses différences entre un incident de production classique, dont la durée est en heures, au pire en jours, et une attaque cyber pour laquelle la résolution court sur des durées en semaines, voire en mois, car les mécanismes classiques ne jouent pas. Reconstruire 6 000 postes de travail à la main en l’absence de mode opératoire (et ce n’était pas le seul défaut de préparation, comme on va le voir), cela prend mécaniquement plusieurs semaines : environ quatre pour les services essentiels (messagerie, etc.), et de deux à trois mois pour l’intégralité du périmètre. Face à un tel impact, si cette entreprise n’avait pas été filiale d’un grand groupe, elle aurait, à notre sens, tout simplement disparu, pour des raisons autant financières que techniques. 

Le temps de l’analyse

Il est maintenant temps de comprendre les raisons qui l’ont conduite à être victime de cette attaque. Le SI a été défaillant sur presque la totalité de la chaîne de protection. Défaillant sur la protection active basique des postes de travail et des environnements, à savoir les antivirus, les EDR… qui n’étaient pas installés ou pas à jour (ou les deux !). Défaillant aussi sur la politique d’habilitation. À titre d’exemple, tous les utilisateurs étaient administrateurs de leur poste de travail ! La propagation d’un vecteur d’attaque est grandement facilitée dès lors qu’il rencontre des comptes administrateurs locaux permettant d’installer silencieusement tout ce que l’on veut sur le poste de travail. Défaillant encore parce sans moyen de détection (SOC⁴ ou équivalent – d’ailleurs, la méthode de compromission initiale n’a pu être identifiée ; probablement du phishing avec chargement du code malveillant sur le PC, comme c’est souvent le cas). Défaillant, enfin, parce qu’aucun moyen de reconstruction massive n’avait été mis en place, et encore moins testé⁵. Ainsi, ces parades actives de prévention et de réparation étaient inexistantes, ce qui engendra la catastrophe décrite précédemment.

Une entreprise est complètement à découvert si ses systèmes offrent des vulnérabilités connues des attaquants (et il est très facile pour eux, de nos jours, de savoir quelles elles sont, si elles sont ouvertes, exposées), s’il n’existe pas de processus de protection périphérique empêchant quiconque de s’introduire dans les environnements, enfin s’il n’y a pas d’hygiène locale (habilitations, antivirus, patchings, etc.). Pour prendre une image simple qui parlera : cela revient à recouvrir une table de billets de banque et à ouvrir en grand les portes qui donnent sur la rue en pensant que personne ne viendra se servir. Comme on n’a pas non plus de système de détection qui pourrait alerter sur la présence d’intrus, on ne les aura pas vu passer ; et puis évidemment on ne dispose pas légalement d’une imprimante pour reconstituer le tas de billets. S’ils sont perdus, ils sont perdus (pour vous). 

C’est ce qui arrive quand les grands classiques Detect & Protect, piliers fondamentaux de la cybersécurité, ne sont pas appliqués : ils vous laissent à découvert face à des attaquants qui, aujourd’hui – nous traitons ici d’un événement remontant maintenant à sept ans, pas tout à fait récent, mais pas vieux non plus – ont encore affiné leur toolkit. Le darkweb propose dorénavant des kits d’attaque packagés, appelés ransomware as a service. Des kits prêts à l’emploi pour détecter des vulnérabilités et les exploiter, assortis de mécanismes financiers qui n’ont rien à envier à la sphère commerciale : payables en une fois et utilisables à volonté, ou bien acquittés par versement sous forme de commissions d’une partie des “bénéfices” dérivés⁶. 

Du loisir qu’elle pouvait être il y a 10-15 ans, quand des hackers se faisaient la compétition à qui arriverait à craquer le premier un système, la cybercriminalité est devenue un business criminel évalué en milliards, que représentent les rançons, l’extorsion, le vol de fonds, tous s’effectuant par le scénario décrit ou par bien d’autres…

Faire contre mauvaise fortune bon cœur, mais surtout faire évoluer les pratiques

J’étais, à l’époque, DSI d’une filiale d’un grand groupe et c’est à double titre que j’ai été témoin de cette attaque : d’abord en tant que confrère du DSI concerné, et en second lieu, interpellé par cette situation, j’ai rapidement souhaité savoir si l’entreprise dans laquelle j’exerçais se trouvait en situation de risque comparable pour mesurer quels étaient les moyens de protection et de réparation en présence, ou à acquérir. Il se trouve que nous n’avons pas subi cette attaque du fait que les moyens de protection étaient en place, notamment l’hygiène de base (utilisateurs non-administrateurs du poste, systèmes patchés, antivirus présents) qui a permis que son vecteur ne puisse se propager. On n’en dira pas autant des systèmes de reconstruction, qui n’étaient, lors, pas tout à fait à niveau. Mais à l’époque, ce type de menace n’était pas perçu ! Autant la menace de perte physique d’un Data Center était connue (et l’on opérait deux Data Centers, des Plans de Reprise d’Activité classiques…), la menace logique de perte d’une application était connue – c’est “l’incident de prod” pour lequel on a des mesures adaptées –, autant on était mal préparé à la perte volumétrique d’un environnement. Aujourd’hui, on dispose des mécanismes adéquats. Idem pour la partie Postes de travail : à l’époque ce n’était pas une chose complètement éprouvée. De nos jours, la reconstitution de milliers de postes peut se faire plus rapidement, en dépit du fait que cela reste des mécanismes compliqués à mettre en place, comme tout ce qui se veut “à l’échelle”. Les techniques de partitions cachées servant de points de restauration des postes de travail permettent de reconstituer un environnement à une date dans le passé qui autorise au moins le redémarrage, la réapplication des politiques, les installations… Cela reste un défi.

Le type d’incident que nous avons décrit, et qui est arrivé à bien d’autres, a fait évoluer les choses en ce qu’il a fait prendre conscience aux DSI, et surtout aux utilisateurs, qu’il fallait arrêter de ne pas patcher et que la mise à niveau des systèmes était impérative. Si l’on revient un peu en arrière, dans les années 2000/2010, que se passait-il ? On installait des postes de travail à un niveau donné, puis on n’y touchait plus, car on se disait “À chaque fois, il y a des effets de bord : une application bizarre ou une macro Excel qui ne fonctionne plus, le rendu de l’application qui change⁷.” Jusqu’à ce que Microsoft explique qu’il ne prend plus en charge l’environnement et n’assure plus la sécurité, obligeant à un saut quantique (Windows XP à 7, 7 à…) bravement mené par un projet sur trois ans… Ce type d’événement a permis de faire bouger les lignes que les DSI avaient du mal à manœuvrer pour être maintenant en mesure de dire : “Il faut faire des mises à jour permanentes et ce n’est pas optionnel”. Aujourd’hui, nous sommes dans une cinématique où l’on suit les versions semestrielles de Windows sur les postes de travail (et on n’attend pas cinq ans pour les mettre en place !), où l’on fait du patching régulier dans un environnement M365, ces mises à jour régulières étant quasiment inaperçues et indolores. Ce type d’événement a contribué à éveiller les consciences, d’une part sur la nécessaire hygiène de base de protection et des bonnes pratiques, et d’autre part sur le fait que l’obsolescence et le manque de patching sont des vecteurs majeurs de menaces et de risques.