kaptn - Fotolia

Ransomware : dans les coulisses d’une attaque menée avec… BitLocker

Les assaillants ont retourné la fonctionnalité BitLocker de Windows contre leur victime, après avoir mis la main sur un contrôleur de domaine… via un Windows Server 2003 oublié de tous. Mais les sauvegardes ont joué leur rôle.

Thomas, dont nous avons changé le nom, est soucieux d’apporter sa contribution à la lutte contre la menace de l’extorsion numérique. Il a souhaité partager avec nous la malheureuse expérience de son entreprise, parce que pour lui, « ça peut arriver à tout le monde. Aujourd’hui encore, c’est trop souvent encore traité comme un secret… de polichinelle ». Mais pour respecter le souci de discrétion de sa direction, nous tairons aussi le nom de son entreprise.

Pour Thomas et ses collègues, tout commence un matin, en semaine, un peu avant 8h, lorsque quelques sites commencent à appeler s’inquiétant de ne plus avoir accès à l’intranet. « En commençant à enquêter, je me suis aperçu que les serveurs DNS ne répondaient plus. En cherchant à y accéder, je me suis trouvé face à une page bleue de récupération BitLocker », explique Thomas. Cette fonctionnalité native de Windows avait été détournée par les assaillants pour faire chanter son entreprise.

Une autre facette du Shadow IT

En fait, l’attaque en elle-même avait commencé plus tôt au cœur de la nuit. Les cyberdélinquants se sont appuyés sur une machine sous Windows Server 2003… dont personne, en interne, n’avait plus conscience de l’existence. Elle n’était pas maintenue, mal protégée, et non documentée. Mais cette machine disposait d’un accès sans bornes au système d’information, et aucun système de gestion des comptes à privilèges (PAM) n’y était installé : « l’attaquant est resté dessus durant quelques heures. À partir d’elle, il a réussi à récupérer les identifiants d’administration du contrôleur de domaine, avant de rebondir dessus en RDP ».

De là, les assaillants ont lancé un script PowerShell pour faire l’inventaire de toutes les machines rattachées à l’unité organisationnelle du contrôleur de domaine et voir si elles étaient joignables. BitLocker a alors été activé sur toutes celles qui répondaient, avant redémarrage automatique au bout de trois heures. Le système de supervision de la production a permis de mettre la main sur le script PowerShell en question.

De multiples leçons

Ce qui a sauvé l’entreprise, ce sont ses sauvegardes, ou plutôt les sauvegardes des sauvegardes. Car les backups primaires ont aussi été attaqués. Mais les backups secondaires sont restés inaccessibles aux cyberdélinquants : « tout était là propre et pleinement intègre. C’est grâce à cela que nous avons pu tout restaurer en l’espace d’un peu plus d’une semaine ».

Si l’histoire s’est bien terminée, Thomas n’en retire pas moins une certaine frustration : « notre enquête n’a pas permis de remonter à la source de l’intrusion, que ce soit un e-mail, un service RDP exposé sur Internet ou un serveur VPN vulnérable. L’attaquant a pu effacer bon nombre de ses traces, que ce soit les logs locaux des machines ou les serveurs syslog ».

Alors dans le doute, « nous avons changé beaucoup de choses pour renforcer notre sécurité ». Et pas question de remonter la gestion des journaux d’activité à l’identique : « il y aura de l’isolation, pour éviter que ce type de destruction ne soit possible ». Mais surtout, Thomas insiste sur la première leçon qu’il retire de l’aventure : faire très attention à tout ce qui est installé dans le SI, par soi-même comme par des tiers, ainsi qu’à ce que ce soit bien documenté. Et maintenu rigoureusement.  

Pour approfondir sur Gestion de la sécurité

Close