DÉMANTÈLEMENT DE BLACKENERGY, PARTIE 2 – « LA MARQUE »

Je ne vais pas faire un discours sur ce qu’est un cadre BlackEnergy puisque beaucoup a déjà été écrit à ce sujet sans moi, cependant je veux me référer aux informations de ce particulier avis:

Tout le monde, voici le Flashplayer!

Lors de l’enquête sur l’attaque contre notre infrastructure, nous avons détecté divers échantillons de logiciels malveillants et parmi eux, Flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/)En bref, flashplayerapp extrait main_light.dll dans son propre espace mémoire et lui transfère le contrôle. Cette bibliothèque est une version légère de BlackEnergy et est utilisée pour la communication C&C afin de télécharger la charge utile principale avec des fonctionnalités dépendantes des objectifs poursuivis par l’attaquant. Il crée un fichier : C:UsersuserAppdataAdobecache.datBien qu’il soit crypté, ce fichier contient diverses informations, y compris la version de construction (telle que 2015lstb), l’adresse du centre de commande et de contrôle à partir duquel il peut récupérer diverses charges utiles (telles que hxxps://188.40.8.72/l7vogLG/BVZ99/rt170v/solocVI/eegL7p.php) etc. En examinant cet échantillon, j’ai détourné mon attention du C&C alors qu’une partie particulière du code a attiré mon attention, car c’était un signe évident de l’utilisation d’une technique appelée permutation de code. Permettez-moi de traduire une citation de cette source http://hacks.clan.su/publ/11-1-0-481:

Voici comment le fragment de code ressemblait (les instructions ajoutées par le moteur de permutation sont mises en évidence en rouge et elles n’affectent pas du tout la fonctionnalité, elles rendent simplement le code plus difficile à comprendre) :En supprimant les chaînes inutiles, nous obtenons un mécanisme qui traite tous les noms de fonctions dans kernel32.dllen les transformant en une certaine forme de hachage qu’il compare ensuite à une valeur :Recréons ce mécanisme en utilisant C comme exemple. En conséquence, nous recevons un utilitaire qui peut produire pour nous un « dictionnaire » contenant les noms de toutes les fonctions dans la bibliothèque kernel32.dll et les valeurs de hachage de ces noms. Essayons de rechercher les valeurs de hachage que nous avons obtenues lors de l’analyse inverse du code dans notre nouveau « dictionnaire ». Premièrement, nous recherchons la valeur du registre EAX (0x5147F60F), puis la comparons à la valeur de référence :Notre théorie fonctionne : notre échantillon a traité le nom de la première fonction, créé le hachage et le compare maintenant à la valeur de référence qui est contenue dans le tampon (0xC8AC8026). Nous recherchons cette valeur et voilà… nous obtenons la fonction LoadLibraryA !Pour éviter un autre mur de texte en exemple, je mentionnerai simplement que notre « échantillon » utilise la même approche pour rechercher une autre fonction appelée GetProcAdress.En utilisant ces deux fonctions, notre « échantillon » peut charger d’autres bibliothèques et extraire les adresses des fonctions dont il a besoin.

Les traces laissées par l’Engine

La technique de rendre l’analyse de code statique difficile via un appel de fonction basé sur une valeur de hachage plutôt que sur son nom n’est pas nouvelle. Cependant, elle m’a conduit à la pensée suivante : peu importe comment le code malveillant est traité, nous connaissons l’algorithme de hachage des noms des fonctions et nous pouvons donc rechercher ces deux fonctions (LoadLibraryA et GetProcAdress) dans le code. J’ai donc commencé à les chercher dans internetz pour les mentions de ce hachage (0xC8AC8026) pour voir si quelqu’un avait utilisé le même moteur que notre exemple auparavant et à ma grande surprise, j’ai trouvé quelque chose :Ce hachage est mentionné pour la première fois en 2006 (l’article ne peut être trouvé que sur archive.org) : https://web.archive.org/web/20060614030412/http://osix.net/modules/article/?id=789

Plus tard, en 2008, un auteur potentiel de l’algorithme fait son apparition sur le forum :https://exelab.ru/f/index.php?action=vthread&forum=6&topic=11845

Ensuite, en 2009, un article d’analyse concernant le shellcode MS08-067 est publié sur blogs.technet.com :  http://blogs.technet.com/b/srd/archive/2009/06/05/shellcode-analysis-via-msec-debugger-extensions.aspx

Puis en 2013, le magazine « XAKEP » (un des plus grands médias russes sur l’informatique et la sécurité de l’information) publie un article https://xakep.ru/2011/06/23/55780/ où ils mentionnent exactement le même algorithme qui crée le même hachage (!):Attendez une seconde, la situation que nous avons ici est que le même algorithme qui génère les mêmes valeurs de hachage est utilisé depuis plus de 10 ans et pourtant personne ne l’a remarqué ? Si cela devait être autrement, alors pour que le flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/) soit le même qu’il apparaît maintenant, il serait impossible de rester inaperçu par les solutions antivirus alors que nous vivons déjà en 2016 :Il y a une « marque » claire laissée par ce moteur de permutation concret qui a été utilisé dans notre échantillon analysé et cela ressemble à une signature valide pour moi. De plus, il est assez facile à suivre directement dans le texte clair :Eh bien, nous avons nos hypothèses et la théorie est renforcée, alors passons à la pratique et essayons de transformer nos conclusions en une signature/règle Yara :

rule API_Hash

{meta: description = « Hash of LoadLibrary that is {26 80 ac c8} et GetProcAddres {ee ea c0 1f} » 

strings:

$a = {26 80 ac c8}

$b = {ee ea c0 1f}

condition: $a and $b

}

La seule chose qui reste à faire maintenant est de la tester contre divers échantillons (par exemple, d’un laboratoire antivirus) afin de découvrir combien exactement de codes malveillants ont été réellement emballés par ce moteur ?
À ce stade, je ne peux que dire qu’il m’a été possible de mener l’expérience sur un très petit nombre d’échantillons dans l’une des entreprises antivirus, pourtant les résultats en valent bien la peine ! Parmi les échantillons capturés, nous avons :Win32/Spy.Bebloh (cheval de Troie bancaire) — http://www.virusradar.com/en/Win32_Spy.Bebloh/detailWin32/PSW.Fareit (Cheval de Troie pour voler des mots de passe) — http://www.virusradar.com/en/Win32_PSW.Fareit/detailWin32/Rustock (Porte dérobée) — http://www.virusradar.com/en/Win32_Rustock/detailWin32/TrojanDownloader.Carberp (Dropper installant le cheval de Troie bancaire Carberp) — http://www.virusradar.com/en/Win32_TrojanDownloader.Carberp/detailWin32/Kelihos (Expéditeur de spam) — http://www.virusradar.com/en/Win32_Kelihos/detailCette liste ne contient que des familles bien connues. Ces deux valeurs de hachage apparaissent également dans d’autres familles de logiciels malveillants, y compris les ransomwares / les crypteurs de fichiers (Win32/Filecoder.HydraCrypt), un mineur de Bitcoin (CoinMiner.LC), un WinLocker (LockScreen.AQT) et d’autres.

Pour l’instant, je peux également ajouter que cette règle Yara relativement simple n’a pas conduit à un seul faux positif à ce jour, mais les tests n’ont été effectués que sur quelques dizaines d’ordinateurs. Par conséquent, j’exprime vraiment mes espoirs qu’après la publication de cette recherche, Toi (!) et ceux qui ont lu jusqu’ici partageront leurs retours qui seront suffisamment importants pour prouver ou réfuter la précision de cette règle ! Bien sûr, utiliser seulement huit octets pour une signature est exceptionnellement petit et la règle attrapera très probablement certains fichiers « légitimes ». Néanmoins, cette règle Yara légère peut vivre dans un bac à sable comme partie d’une logique d’analyse plus complexe.

Conclusions

L’objectif de cet article n’est pas l’ingénierie inverse du malware BlackEnergy mais je veux plutôt souligner le fait que les outils utilisés lors de l’assemblage d’un code malveillant laissent leurs traces et peuvent conduire à l’apparition d’indicateurs utiles qui peuvent être utilisés pour la défense. Et ces indicateurs peuvent passer inaperçus pendant un temps assez long…

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