Incident Vanadium (Partie 1) : vous avez des backups à jour mais vous allez vivre un cauchemar

Streamscan se spécialise dans la détection et l’élimination des intrusions dans les réseaux informatiques. Nous sommes constamment appelés à intervenir directement en entreprise pour limiter les dégâts pendant une attaque informatique. Nos interventions s’appuient sur les technologies les plus avancées en intelligence artificielle et également sur l’expertise de nos experts en cybersécurité.

Lors d’un déploiement de notre équipe de réponse aux incidents, nous avons documenté le déroulement de notre intervention. Voici le cas Vanadium.

Apercu de l’incident Vanadium

Il est courant d’entendre dire que pour se protéger efficacement contre les rançongiciels il suffit d’avoir des sauvegardes à jour. Cela semble évident et tout le monde le répète. Mais est-ce vraiment le cas?

Dans un cas d’incident que nous avons géré dans la région de Montréal, l’organisation disposait de backups à jour et malgré cela la gestion de l’incident fut très éprouvante.

Lisez plutôt.

L’article est séparé en 2 parties:

1 - Le confinement de l’incident (rançongiciel)

2- Ne jamais lâcher

Partie 1 - Le confinement de l’incident

Samedi 11h03 - prise de contact initial: notre téléphone sonne. Au bout du fil, une compagnie dans le domaine du commerce en detail de Montréal qui s’est fait pirater. 18 de ses serveurs ont été infectés par un rançongiciel et le pirate demande 200 000$ US à payer en bitcoin. L’incident a eu lieu le vendredi autour de 2AM et personne n’a pu travailler au cours de la journée. L’équipe TI interne a essayé de régler le problème et après plusieurs heures de travail acharné sans repos, elle n’est pas sûre de sa capacité à régler le problème. De plus, l’équipe soupçonne que le pirate soit encore dans le réseau. L’équipe TI a donc décidé de chercher de l’aide externe afin de s’assurer que l’incident soit géré dans les règles de l’art.

Samedi à 11h30 - debriefing: nous réunissons les membres de notre équipe de réponse aux incidents et faisons un debrief sur la situation. 2 membres de notre équipe sont dépêchés dans les locaux de la compagnie victime du rançongiciel. En parallèle, nous assistons la compagnie a distance pour mettre en place les mesures de confinement immédiates.

Samedi à 12h43 - arrivée dans le locaux de la compagnie et meeting de collecte d’information : notre équipe de réponse aux incidents arrive dans les locaux de la compagnie piratée. Nous organisons une rencontre de collecte d’informations additionnelles et demandons à connaître toutes les mesures prises depuis le début. Il ressort que tous les 18 serveurs infectés sont de type Windows. Un fichier de demande de rançon a été déposé dans chaque répertoire chiffré par le rançongiciel. L’organisation ne dispose pas d’un plan de réponse aux incidents et un membre de la Haute direction a demandé de contacter le pirate afin de connaître ses intentions. Le pirate exige le paiement de 200 000$ US, payable en bitcoins.

La situation est tendue, le niveau de stress est au maximum et la Haute direction met la pression sur l’équipe TI pour savoir quand le problème sera réglé. Quel cauchemar pour l’équipe TI.

Samedi à 13h05 - la compagnie semble avoir des sauvegardes: Il ressort que l’organisation fait des sauvegardes à distance chez un fournisseur situé à Toronto. Ce fournisseur a été contacté afin de confirmer si les sauvegardes n’ont pas été touchées par le rançongiciel. L’équipe TI est en attente de la réponse du fournisseur.

Samedi 13h08 - nous prenons les choses en main et établissons le plan d’actions pour gérer l’incident et revenir en production le plus rapidement possible. La 1ère action consiste à présenter clairement la situation à la Haute Direction de façon transparente: c’est un gros problème, ce ne sera pas facile mais on va y arriver. Il est inutile de mettre la pression sur l’équipe TI car cela ne changera rien. Nous déroulons notre plan d’actions:

1- vérifier que l’incident est totalement confiné et ne peut plus se propager

2- s’assurer que le pirate n’est plus dans le réseau

3- Etc.

Nous présentons notre plan d’actions à la Haute Direction et nous avons son accord pour avancer. Go! Les choses sérieuses peuvent commencer.

Samedi 13h34: isolation complète du réseau: en faisant nos investigations initiales, nous découvrons rapidement qu’une copie du rançongiciel a été déposée sur d’autres serveurs du réseau, mais n’ont pas été exécutés (heureusement).

Cette découverte choque l’équipe TI et augmente son niveau de stress. Elle n'est plus en mesure de confirmer le nombre exact de serveurs que l’organisation détient. Elle n’est également pas en mesure de confirmer si l’organisation a des serveurs dans le Cloud ou non.

Dans un tel cas, la meilleure chose à faire consiste à couper tout le réseau d’Internet. Si le pirate est encore dans le réseau, il y sera automatiquement éjecté. La coupure d’Internet fait baisser la pression et le directeur TI nous dira ‘heureusement que vous êtes là! Un moment j’ai eu peur que le pirate découvre qu’on l’a vu et que tous nos autres serveurs se mettent à se faire chiffrer’. Ouf de soulagement pour l’équipe TI.

Samedi 13h57 - la fumée blanche s’échappe - les sauvegardes sont bonnes: l’équipe TI de l’organisation victime reçoit la réponse de son fournisseur de solution de sauvegardes. Tout le monde retient son souffle.

Finalement les sauvegardes sont bonnes et peuvent être restaurées. Ouf!! Quel soulagement. La Haute Direction est informée et nous lui demandons de ne plus répondre au pirate. L’équipe TI s’active à démarrer le téléchargement des sauvegardes.

Samedi 14h48 - identification de tous les serveurs sur lesquels une copie du rançongiciel a été déposée. Nous branchons notre technologie de détection de cybermenaces CDS dans le réseau. En plus de sa capacité à détecter et bloquer les attaques qui ciblent un réseau, cette technologie peut balayer tout le parc informatique de l’organisation afin d’identifier les ordinateurs sur lesquels une copie d’un rançongiciel a été déposée.

Nous trouvons 13 autres serveurs et 4 postes de travail ayant une copie du rançongiciel. A cette étape, l'organisation victime sait exactement à combien de machines de son parc informatique le pirate a eu accès.

Nous faisons isoler toutes les machines concernées et la Haute direction en est informée.

Samedi 15h14 - début des investigations approfondies: nous débutons les investigations approfondies afin de savoir comment le pirate a pu entrer dans le réseau. Nous collectons les logs sur certains serveurs pertinents qui ont été infectés.

Parallèlement à l’analyse, une copie du rançongiciel a été envoyée à notre équipe de rétro-ingénierie d’outils malicieux (reverse-engineering de malware) pour analyse à distance dans notre lab.

Samedi 15h43 - début de la reconstruction des serveurs infectés par le rançongiciel: lorsqu’une machine est infectée par un rançongiciel, il faut le reconstruire à partir de zéro. L’équipe TI interne démarre la réinstallation des serveurs. Une fois que les serveurs sont réinstallés nous allons les endurcir pour renforcer leur sécurité. L’on pourra ensuite installer les applications et restaurer les données.

Samedi 15h47 - premier choc : l’équipe TI a démarré le téléchargement des sauvegardes mais il y a une mauvaise nouvelle. Les sauvegardes sont volumineuses (plusieurs dizaines de Terabytes) et la bande passante du réseau du siège social de l’organisation victime n’est pas très élevée. Ça prendra environ 60h pour télécharger les sauvegardes! Choc total pour tout le monde, le Directeur TI en premier! C’est 2.5 jours! Impensable!

La Haute Direction est informée. Il n’y a pas d’autres solutions viables pour l’instant, alors l’on relance le téléchargement des données. Le temps de téléchargement est mis à profit pour construire des serveurs et continuer les investigations.

L’équipe TI en profite pour prendre un moment de repos: les membres de l’équipe ne se sont pas reposés depuis le vendredi.

Samedi à 17h - nous avons trouvé comment le pirate est entré dans le réseau. Nos investigations nous ont permis d’identifier que le pirate est entré dans le réseau via une attaque du serveur d’accès à distance RDP. Cela fait plus de 2 mois que le pirate a pris le contrôle du réseau. L’attaque a fait beaucoup de bruit mais l’organisation victime ne disposait pas de technologie de détection d’intrusions (IDS/IPS/NDR) et ne surveillait pas la sécurité de son réseau. Une aubaine pour les pirates.

Samedi à 18h : le téléchargement des sauvegardes continue. C’est l’heure de commander la Pizza car la nuit risque d’être longue. Nous essayons de remonter le moral à l'équipe TI interne, c’est la réalité de la gestion des incidents de cybersécurité, mais nous sommes là pour les aider.

Nous nous assurons aussi qu’il y a assez de café car la nuit risque d’être longue.. Très longue. Vous vous en doutez, le café est un outil de travail des équipes de réponse aux incidents!

Samedi à 20h37 - début du cauchemar: le téléchargement des données s’arrête à nouveau brutalement. Tout est à recommencer. Encore un espoir qui se brise. L’équipe TI interne s’effondre, mais ce n’est pas le moment d’abandonner.

Nous continuons de motiver la troupe: c’est quelque chose qui arrive souvent et il faut trouver une solution. Nous allons y arriver!

Lire la suite de l'histoire : Partie 2 - Ne jamais lâcher!