Le cas Rubidium01 : suivez pas à pas une intervention de Streamscan lors de la réponse à un incident de sécurité (infection par un ransomware)

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 entreprises 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 donc le cas Rubidium01.

Vendredi 17h45

Un bureau de consultation en TI nous contacte pour nous signaler qu’un de leurs gros clients subit une attaque informatique. L’un des administrateurs système a constaté que plusieurs serveurs de productions redémarraient tout seuls. Au redémarrage, un message s’affichait à l’écran indiquant que le disque dur a été chiffré et qu’une rançon doit être versée pour recouvrir les données. À ce moment, 17 serveurs étaient infectés. Pendant que nous discutons, mon interlocuteur est informé que 5 serveurs supplémentaires ont redémarré et sont infectés. Tous les serveurs infectés ont la même version Windows et le même antivirus. Notre interlocuteur nous informe aussi que son client a reçu un courriel de demande de rançon en bitcoins de l’ordre de 300 000$ CAN et qu’il a 48h pour payer sinon la rançon doublera. Le bureau de consultation en TI nous communique l’adresse de l’entreprise.

Vendredi 17h58

Notre coordinateur de gestion des incidents organise une téléconférence avec les membres de notre équipe de réponse aux incidents pour préparer le déploiement. Le mode opératoire (redémarrage de serveurs infectés) nous fait penser qu’il pourrait y avoir beaucoup plus de serveurs infectés. Il est impératif d’agir le plus rapidement possible pour contrecarrer l’incident et éviter qu’il se propage dans le réseau de l’entreprise. Trois experts de notre équipe se dépêchent à se rendre chez l’entreprise infectée.

Vendredi 18h30

Nous passons à notre bureau pour récupérer deux serveurs CDS déjà configurés prêts à être branchés au réseau du client. Nous embarquons également un clavier, un écran d’ordinateur, des câbles d’alimentation, des câbles réseau ainsi que des disques durs et DVD vierges. Nous emportons également avec nous deux ordinateurs portatifs : le 1er contient des outils d’investigation et de collecte d’éléments de preuve tandis que le 2e contient un environnement d’analyse, d’autopsie et de rétro-ingénierie de virus et outils malicieux (sandbox).

Vendredi 18h53

Notre coordonnateur aux réponses aux incidents arrive dans les locaux du client avec deux serveurs sous le bras. Une brève rencontre est organisée avec le directeur TI de l’entreprise afin de collecter des informations sur l’évolution de la situation et les actions de mitigation qui ont été éventuellement prises jusque-là. Il ressort de cela qu’au total 27 serveurs sont infectés. Parmi ceux-là, des bases de données très sensibles et vitales pour les opérations d’affaire du client. Par mesure de prudence, tous les serveurs ont été éteints. Une règle de pare-feu a aussi été créée pour bloquer tout le trafic internet. Nous recommandons une stratégie de communication au directeur TI afin que l’entreprise ait un contrôle total sur l’information diffusée au sujet de l’incident. En effet, si la communication n’est pas maîtrisée, il pourrait y avoir plusieurs versions de l’incident.

Vendredi 18h58

Les deux autres experts de notre équipe arrivent chez le client. Le coordinateur de la réponse aux incidents leur présente l’état des lieux. Un plan d’action est défini et communiqué au directeur TI du client.

Vendredi 19h12

Dans une telle situation, la première action à prendre d’urgence est de confiner l’incident pour éviter qu’il y ait par exemple une exfiltration de données ou que l’incident se propage dans le réseau. Nous recommandons la mise en place des règles de coupe-feu permettant d’isoler complètement la zone des serveurs du reste du réseau de l’entreprise.

Vendredi 19h25

Nos experts en cybersécurité débutent l’installation de notre technologie CDS dans le réseau du client. L’objectif est de permettre de détecter en temps réel les tentatives d’exfiltration de données ou encore les tentatives de propagation de l’outil malicieux à travers le réseau. Le CDS nous permettra d’avoir la cartographie de l’ensemble des serveurs déjà infectés dans le réseau.

Vendredi 20h00

Les deux instances CDS sont installées et fonctionnelles dans le réseau du client. Le réseau est sous surveillance afin de détecter les tentatives d’intrusions, les cybermenaces ou toute tentative d’exfiltration des données. La notification par courriel est activée. Après quelques minutes d’analyse, le CDS détecte des comportements suspects dans le réseau. Une série d’alertes s’affichent dans le tableau de bord de notre système de détection. Nos experts débutent à analyser les événements de sécurité générée.

Vendredi 20h15

Début des investigations. Priorité numéro 1: trouver une copie du ransomware afin de comprendre son mode opératoire. Une machine virtuelle d’un serveur infecté est installée dans notre sandbox pour analyse. Nous trouvons le fichier exécutable du ransomware dans un répertoire.

Vendredi 20h45

Nous procédons à l’analyse dynamique du fichier exécutable du ransomware afin de mieux comprendre son comportement, son mode de persistance et de propagation. Nous extrayons les indicateurs de compromission (IOC) du ransomware qui sont les artefacts qui permettent de le caractériser de manière unique (par exemple : nom et taille du fichier exécutable du ransomware, nom des processus créés, clés de registres ajoutés, noms de domaines ou adresses IP avec lesquels le ransomware communique). Nous sommes en mesure d’identifier le rançongiciel (ransomware) comme étant ARENA (Crysis Dharma). Il s’agit d’un malware apparu en 2017 et qui a déjà fait des milliers de victimes à travers le monde. C'est aussi l'un des ransomwares les plus actifs en 2020.

Vendredi 20h53

Le client est informé des résultats obtenus. Nous recommandons toujours de ne pas payer la rançon demandée par le pirate. Le client accepte.

Vendredi 21h32

Détermination du mode propagation du ransomware. Par analyse des flows de communication réseau générés lors de l’analyse dynamique du ransomware, nous sommes en mesure de confirmer que le ransomware ne peut pas se propager tout seul. Cela suppose que le pirate informatique se connecte sur chaque serveur et exécute manuellement le ransomware.

Vendredi 21h37

Débriefing avec le client. Nous demandons le changement des mots de passe de tous les comptes utilisateurs et administrateurs des serveurs du réseau (comptes locaux et Active Directory). Le pirate utilise certainement un mot de passe pour se connecter aux serveurs. Ce changement évitera que le pirate puisse compromettre des serveurs supplémentaires.

Vendredi 21h39

Nous créons un modèle comportemental du ransomware et l’intégrons au CDS. Ce nouveau modèle permet au CDS de détecter les autres variantes du ransomware. Le nouveau modèle comportemental est partagé chez les autres utilisateurs du CDS, nous pouvons éviter ainsi que d’autres entreprises subissent la même attaque.

Vendredi 21h42

L’un des CDS génère des alertes concernant des attaques qui ciblent un serveur web. Le client nous confirme qu’il s’agit d’un de leurs serveurs web transactionnels. Nous indiquons les mesures à mettre en place pour bloquer l’attaque.

Vendredi 22h45

Comme dans tous les cas de gestion d’incident, l’on sait quand l’on commence, mais jamais quand on ne finit. Nous commandons de la pizza, des caisses d’eau, des fruits et des collations. La nuit risque d’être longue. L’équipe est motivée et décidée à régler la situation le plus rapidement possible pour limiter les impacts dans l’entreprise.

Samedi 23h26

Le directeur IT nous informe qu’il a reçu un courriel du pirate qui lui annonce que si le paiement de la rançon n’est pas effectué avant 24h, le montant doublera. Le directeur TI souhaite négocier, ce que nous lui déconseillons vivement.

Samedi 1h00

Les investigations continuent…

Samedi 1h35

Le CDS génère des alertes concernant des systèmes infectés. Après renseignement, il s’agit de postes de travail d’employés. Surprise du client : il y’a un antivirus à jour sur chacun des ordinateurs concernés. Nous demandons la déconnexion des ordinateurs en question. Ils seront nettoyés plus tard. Nous demandons également la mise en place des règles de pare-feu pour bloquer les communications vers les adresses IP distantes avec lesquels les ordinateurs infectés essaient de communiquer. Les investigations continuent.

Samedi 2h45

Notre équipe identifie la source du problème. La pression retombe tranquillement. Nous sommes remontés au patient zéro (1er serveur infecté) et sommes en mesure de confirmer que le pirate s’est connecté à ce serveur via un compte de support disposant de privilèges administrateurs puis a exécuté le ransomware manuellement. Le même compte de support existe sur tous les autres serveurs infectés. Cette machine a été compromise via une attaque par brute force (ciblant le protocole RDP) venant d’internet. Nous proposons des mesures de renforcement des accès RDP à distance.

Samedi 3h43

Débriefing avec le directeur TI du client. Nous lui indiquons les mesures à prendre : réinstaller les serveurs infectés à partir de zéro, restaurer les backups de données, renforcer le contrôle d’accès RDP à distance, etc.

Samedi 3h55

L’un des membres de notre équipe d’experts rentre chez lui pour se reposer. Il prendra le relais en matinée.

Samedi 4h54

À ce stade, nous sommes en mesure de confirmer que tous les serveurs infectés ont été identifiés et isolés. L’équipe TI du client est épuisée, car elle travaille sur le cas depuis jeudi. Vu que l’incident est maîtrisé, ils rentrent chez eux pour se reposer afin d’être en pleine forme pour la suite des travaux. Un de leur technicien TI reste sur place avec nous au besoin. Pendant ce temps, notre équipe de sécurité surveille la sécurité du réseau, identifie les attaques et travaille avec le technicien TI du client pour les bloquer.

Samedi 10h00

Début de l’installation du système d’exploitation des serveurs précédemment infectés. Nous recommandons des mesures de blindage du système d’exploitation des serveurs réinstallés.

Samedi 11h14

Le Directeur TI nous informe que les copies de sauvegarde de données les plus récentes remontent à une semaine. La restauration de ces données est acceptable.

Samedi 12h52

Relance du pirate… le montant va bientôt doubler et il a la courtoise de nous en informer afin d’éviter que la facture soit trop salée. Malgré tout, le pirate nous veut visiblement du bien et est soucieux de ne pas trop nous faire dépenser. Évidemment, sa relance est ignorée.

Samedi 13h00

Notre équipe continue de surveiller la sécurité du réseau. Ils identifient les attaques et travaillent avec le technicien IT du client pour les bloquer. Nous détectons d’autres intrusions dans le réseau de l’entreprise qui ne sont pas en lien avec l’attaque en cours.

Samedi 14h04

Une autre relance du pirate qui commence à être fébrile. Il a compris que la situation pourrait lui échapper…

Dimanche 6h09

Une autre relance du pirate qui veut maintenant négocier. Il a compris que la situation lui a échappé. Nous l’ignorons.

Dimanche 11h

Début de la restauration des données en commençant par les serveurs les plus critiques.

Dimanche 17h

Retour progressif en production.

Pour les deux prochaines semaines, notre équipe accompagne l’équipe TI dans la restauration des serveurs. Pour chaque serveur réinstallé, nous nous assurons qu’il est bien sécurisé. Nous identifions les points d’amélioration immédiate à mettre en place et travaillons avec le client pour leur application.

À la demande du client, notre système de détection de compromission (CDS) est installé de façon permanente dans leur infrastructure. Nous pouvons ainsi assurer la supervision de sécurité post-incidente du réseau du client via notre CDS. De cette façon, le niveau de sécurité de l’environnement du client est optimal. Les attaques et infections identifiées lors de la supervision post-incidente sont remontées au client et nous les aidons à les traiter.