Threat-Intel avec la technologie GLIMPS

il s’agit d’un botnet très connu et répandu, dont les sources sont disponibles publiquement sur GitHub. Il en existe des versions pour de nombreuses architectures, et de multiples variantes.

Cela en fait donc un très bon cas d’espèce pour GLIMPS : nous pouvons le recompiler nous-mêmes pour différentes architectures, compilateurs et options de compilation, afin de mesurer la performance de notre technologie.

Ci-dessous, vous pouvez voir le résultat obtenu lors de l’analyse d’un fichier. Il s’agissait d’une instance de Mirai pour amd64, compilée avec gcc.

En observant les résultats, on peut voir que cet échantillon de Mirai était déjà présent dans la base (sha256 identique remonté en premier). Notre échantillon a bien 100% de corrélation avec lui-même, c’est plutôt rassurant !
Mais il est également corrélé avec d’autres échantillons de mirai, qui bien que différents (les hash du code sont différents du fichier analysé) remontent tout de même avec 100% de corrélation. En effet, la technologie GLIMPS permet de s’affranchir des artefacts induits par le processus de compilation. Du point de vue du concept-code, on voit que les 2 échantillons sont identiques. Notre binaire aurait ainsi été détecté comme un malware de type mirai même si le premier échantillon n’avait pas été présent dans la base.
C’est l’un des intérêts de GLIMPSMalware : inutile de posséder les signatures de chaque variante d’un malware pour les détecter : quelques versions suffiront largement pour détecter l’ensemble des variantes, y compris celles qui n’ont pas encore été créées ou détectées. Vous pouvoir d’ailleurs voir notre Use Case Détection et caractérisation d’un malware inconnu à ce sujet.

Premièrement, notre échantillon de Mirai a bien été détecté comme un exemplaire de la famille mirai… Mais ce qui est également très intéressant dans ce résultat, c’est qu’on voit également une autre famille apparaître : le taux de corrélation est bien entendu plus faible (15%), mais GLIMPSMalware nous indique que Mirai est également proche d’exemplaires de la famille Bashlite.

En creusant un peu, on trouve des informations dans la littérature nous confirmant que Bashlite était l’ancêtre de Mirai. Il est donc logique que les 2 aient du code en commun, ce que GLIMPSMalware a détecté ! Nous avons voulu en avoir le coeur net… le temps de sortir notre logiciel de rétroconception préféré… GLIMPS Audit bien sûr !!!

Notre échantillon Mirai ne possède aucun symbole de debug. En revanche, pour bashlite, l’attaquant avait oublié d’enlever les symboles de debug. Première étape, utiliser GLIMPSAudit ! Nous allons ainsi pouvoir rapatrier la documentation de bashlite dans notre sample mirai.

En comparant nos 2 binaires, on trouve 25 associations dites « de confiance » :

Si on observe dans Ida une fonction au hasard, on voit que, même si dans le détail le code assembleur n’est pas identique, il s’agit bien du même code,et que les deux proviennent sans doute de la même source d’origine (dans le cas précis de cette fonction que nous avons sélectionné parce qu’elle est particulièrement grande, ce qui permet à l’œil humain de rapidement voir les similarités, les graphes sont même extrêmement proches !). Ici, une technique à base de hash aurait nécessairement échoué : dans une fonction de cette taille avec des versions de compilateurs différentes, il est quasiment impossible que toutes les instructions soient strictement identiques.

Dans le cas précis de Mirai dont une version des sources est disponible sur Github on peut même aller beaucoup plus loin : quel que soit le sample que l’on souhaite analyser, il est facile de rapatrier tous les symboles depuis la version publique en la compilant avec les symboles de debug.

Nous pourrions laisser cet exercice au lecteur… Mais ne vous inquiétez pas, GLIMPS Malware le fait automatiquement pour vous !

Si on observe dans Ida une fonction au hasard, on voit que, même si dans le détail le code assembleur n’est pas identique, il s’agit bien du même code,et que les deux proviennent sans doute de la même source d’origine (dans le cas précis de cette fonction que nous avons sélectionné parce qu’elle est particulièrement grande, ce qui permet à l’œil humain de rapidement voir les similarités, les graphes sont même extrêmement proches !). Ici, une technique à base de hash aurait nécessairement échoué : dans une fonction de cette taille avec des versions de compilateurs différentes, il est quasiment impossible que toutes les instructions soient strictement identiques.

Dans le cas précis de Mirai dont une version des sources est disponible sur Github on peut même aller beaucoup plus loin : quel que soit le sample que l’on souhaite analyser, il est facile de rapatrier tous les symboles depuis la version publique en la compilant avec les symboles de debug.

Nous pourrions laisser cet exercice au lecteur… Mais ne vous inquiétez pas, GLIMPS Malware le fait automatiquement pour vous !????

Nous avons vu comment GLIMPS Malware et GLIMPS Audit pouvaient être utilisés efficacement en complémentarité dans une démarche de Threat-Intel.

Contactez-nous pour plus de renseignements, organiser une démonstration ou une évaluation !