04562188764004560258
78130723498442348940
73249795302400546489
04562188764004560258
78130723498442348940
73249795302400546489
04562188764004560258
78130723498442348940
73249795302400546489

02.04.20

Blogue

Incident Thorium : la fin d’une start-up qui n'a pas pu se reléver suite à une infection par un ransomware

Streamscan blog

Jeudi 16h15

Notre téléphone de bureau sonne : le fondateur d’une startup de développement dans l’industrie du divertissement nous explique que son équipe travaille depuis deux ans sur un logiciel révolutionnaire et que malheureusement, leur serveur de développement vient d’être infecté par un ransomware. La startup avait un serveur de sauvegarde qui était connecté directement au serveur de développement. Les sauvegardes ont donc aussi été chiffrées par le ransomware. L’entreprise ne dispose d’aucune autre sauvegarde.

Nous collectons des informations sur les mesures de réponse déjà prises par l'entreprise et prenons l'adresse de la compagnie. Le client nous informe qu’il a déjà échangé quelques courriels avec le pirate qui demande une rançon d’environ 100 000$ payables en bitcoins. La startup en question dispose de très faibles ressources et ne pourrait même pas payer une rançon de 7000$ selon les dires de notre interlocuteur.

Jeudi 16h30

Comme pour toutes les situations d'urgence, nous réunissons notre équipe de réponse aux incidents dans notre salle de gestion des crises pour un débriefing. Dans le présent cas, vu que le client ne dispose d’aucune sauvegarde, le défi est de lui permettre de déchiffrer ses données, sans qu’il ait à payer la rançon.

L’un de nos experts en réponse aux incidents de notre équipe est envoyé chez le client pour prendre la situation en main

Jeudi 18h15

Notre expert arrive dans les locaux de la startup piratée et trouve son fondateur effondré. Un débriefing est fait avec lui et il en ressort très rapidement que la startup joue sur sa survie, car si elle perd son logiciel en développement depuis deux ans, elle devra malheureusement cesser ses activités. Le fondateur a négocié en vain avec le pirate qui refuse tout compromis : il tient mordicus à « son 100 000$ ». Un scénario que nous connaissons parfaitement pour avoir géré plusieurs cas similaires. Dans un tel scénario, le pirate pense avoir souffert et travaillé si fort pour trouver enfin une victime qu’il mérite une grosse récompense. Ceci d’autant plus qu’ils ne sont pas convaincus de faire de nouvelles victimes. C’est généralement l’attitude de pirates débutants ou mal structurés.

Jeudi 18h30

Nous faisons un débriefing téléphone et convenons d’un plan d’action. L’urgence est de trouver une copie du ransomware et de l’analyser afin de voir s’il est possible par un moyen ou un autre, de trouver la clé de chiffrement.

Jeudi 19h03

Une copie du ransomware est trouvée. Notre expert en réponse aux incidents envoie une copie de l’exécutable du ransomware à notre équipe de Détection et Réponse Gérées (DRG) qui, à distance, le disséquera et l’analysera afin de déterminer son comportement, son mode de propagation ainsi que son mode de chiffrement. Le client nous signale qu’il n’y a pas d’urgence à régler la situation. Nous convenons donc que l’analyse du ransomware aura lieu le lendemain.

Vendredi 9h03

Le ransomware est analysé par notre équipe DRG et nous sommes en mesure de déterminer comment il a pu entrer dans le réseau de l’entreprise. Tout a commencé par une attaque par force brute via un serveur RDP (Remote desktop ou connexion à distance) de la startup qui était accessible sur Internet. Une fois que le pirate a eu accès au serveur RDP, il a repéré le serveur de développement, s’y est connecté et a exécuté manuellement le ransomware. Le ransomware n’établit aucune communication externe avec une quelconque unité de commande et de contrôle. Il n’y a pas d’échange de clés de chiffrement. Nous ne sommes donc pas en mesure de trouver la clé de déchiffrement. Nous envisageons des méthodes alternatives de recouvrement de clés de déchiffrent et en informons le client .

Vendredi 13h53

Les autres méthodes de recouvrement de clés de déchiffrement que nous avons essayées n’ont pas été positives. Nous informons le fondateur de la startup et nous sentons son niveau de stress augmenter. Nous pensons qu’il faudrait arrêter les investigations pour ne pas alourdir sa facture d’autant plus que nous avons la certitude que ses données ne peuvent pas être recouvrées sans le paiement de la rançon. Le fondateur nous informe qu’il doit discuter avec ses partenaires et nous revenir.

Vendredi 17h19

Le fondateur nous appelle et nous informe qu’il a entrepris des recherches de fonds pour payer la rançon et que malheureusement le motif de la recherche de fonds rend les prêteurs frileux. Aucun prêt ne lui a été accordé. La cessation des activités de sa compagnie lui semble de plus en plus inéluctable, car il n’a ni l’énergie et ni les moyens de repartir à zéro.

Vendredi suivant 15h00

Nous faisons un débriefing interne et décidons de ne pas facturer le client au regard de la situation qu’il vit.

Une semaine après l’incident, le fondateur nous informe que son entreprise ferme. Triste fin pour une startup qui paradoxalement avait été créée pour divertir… Le pire dans l’histoire : l’attaque n’était pas ciblée. Une attaque aléatoire qui finit de la plus triste façon.

Que vous soyez une grande entreprise ou une PME, si une telle attaque aléatoire ciblait vos infrastructures critiques, sauriez-vous vous relever?