Traquer les Attaquants : de l'email au malware

Résumé #

La vue graph de VirusTotal permet de collecter des IOCs, de se renseigner sur la menace, de découvrir de nouvelles campagnes d’attaque pour, in fine, améliorer sa posture défensive. Dans cet article, je détaille la façon dont j’ai analysé le mail afin de statuer sur sa dangerosité. Les entêtes nous indiquent que cet email tente de tromper son destinataire en usurpant une adresse mail légitime. La vue graph de VirusTotal permet d’en apprendre davantage sur le mode opératoire des attaquants, leurs capacités, leur organisation ainsi que leurs futures actions. Il est ainsi possible, proactivement, de traquer les attaquants dans la nature mais également dans son propre réseau afin de détecter des traces de compromission encore inconnues.

Cet article se base sur le challenge PhishStrike disponible gratuitement sur Cyberdefenders.org. Bien que je détaille la plupart des réponses du challenge, j’ai volontairement eclipsé quelques parties pour me focaliser sur ce que j’ai jugé essentiel, à savoir mon cheminement de pensée et ma méthodologie.

Cet mail est en réalité la première étape vers l’installation d’un logiciel de contrôle à distance (RAT). Le mail contient un lien vers un exécutable qui est un loader dont le rôle est de télécharger d’autres malwares. En analysant les infrastructures des attaquants, j’ai de bonnes raisons de penser qu’il s’agit de BitRAT ; un logiciel malveillant conçu pour pouvoir piloter la machine à distance.

Je tire 3 mesures de sécurité à mettre en place par rapport à cette attaque :

1. Un serveur mail de réception qui vérifie les headers tels que SPF et DKIM (voir plus bas) et qui, à minima, avertit l’utilisateur que le mail est louche, voire le bloque.

2. Une équipe de sécurité proactive qui a le temps d’investiguer sur cette alerte pour la comprendre, réagir en conséquence et vérifier la présence du malware dans le système d’information (ce que je tente de faire ici).

3. Des solutions de sécurité flexibles auxquelles on peut envoyer les IOCs récupérés par l’équipe sécurité afin de bloquer les nouvelles attaques. Cela peut également servir à rechercher automatiquement des traces de compromission dans le système d’information.

Qualification du mail #

Si on sort un peu du challenge, dans la vraie vie d’un analyste Blue Team, on demande souvent de qualifier l’incident. Une alerte sonne et on vous demande un avis sur un document, un fichier, un ensemble d’actions, une IP ou, en l’occurrence, un email. L’idée est de donner un avis sur l’email à propos de sa malveillance ou non. Il s’agit d’une étape assez critique car selon l’avis rendu, cela peut enclencher des processus de réponse à incident, éventuellement l’ouverture d’une cellule de crise etc… D’expérience, on a souvent peu de contexte sur l’incident il faut donc faire avec ce que l’on a. C’est pour cela que dans cette première partie je détaille comment j’analyse cet email afin de statuer sur sa dangerosité.

Je précise que je pars avec peu de connaissance du fonctionnement des emails. C’est pourquoi je ne rentre pas dans les détails techniques du protocole. Je détaille ce que j’ai compris du fonctionnement du système, dans les grandes lignes. J’ai laissé quelques sources pour les lecteurs curieux.

Analyse du mail #

Bon, cette partie va être rapide. Le mail mentionne une pièce jointe… qui n’existe pas. Néanmoins, le mail comporte pas mal de liens cliquables qui renvoient tous vers http[:]//107[.]175.247.199/loader/install.exe. L’IP est connue sur VirusTotal. Peut-être est-ce une technique pour inciter l’utilisateur à cliquer ? On pourrait arrêter l’analyse là et statuer que le mail est malveillant. Cependant, on va quand même analyser les headers car il s’agit de la partie la plus intéressante, techniquement parlant.

SPF & DKIM #

Les clients mails proposent souvent une vue détaillée de l’email. Cette dernière permet d’observer tous les détails techniques (IPs, serveurs mails de transferts…). L’IP émétrice est 18.208.22.104 qui est liée à uptc.edu.co. Un peu d’OSINT sur ces deux éléments m’ammène sur cette page RATS NoPtr - BLACKLIST - MX Toolbox qui indique un ajout de “spf monitor” pour ce domaine avec cette IP. Le site indique également que l’IP et le domaine ont été ajoutés à une blacklist.

Lorsqu’on regarde dans les headers ce que peut bien vouloir dire “SPF”, on trouve spf=softfail pour le sender 18.208.22.104. SPF pour Sender Policy Framework qui est une méthode d’authentification des email qui empêche des attaquants d’envoyer des mails en se faisant passer pour un autre domaine. D’après cette source SPF failures: Hard fail vs Soft fail - Red Sift un softfail indique que l’email n’est probablement pas autorisé. Cela peut vouloir dire que l’IP qui envoi l’email ne correspond pas avec le domaine duquel elle prétend provenir.

Un autre indice est de regarder du côté du header DKIM. DomainKeys Identified Mail permet de vérifier l’intégrité des messages en utilisant des signatures cryptographiques. A noter que ce système est complémentaire avec SPF car DKIM ne permet pas de vérifier l’IP de l’expéditeur. Là encore, le DKIM est renseigné à fail (no key for signature). Cela ne signifie pas forcément une activité malveillante en soit mais en ajoutant le SPF, ce mail commence à devenir louche (si on fait abstraction qu’il contient des liens vers un exécutable). Sur VirusTotal, cette IP ne remonte rien, sûrement car elle est trop ancienne.

L’adresse émetrice est erikajohana.lopez@uptc.edu.co. Avec un peu d’OSINT on tombe et sur des writeup du challenge et sur une adresse mail qui a l’air de réellement exister et est rattachée à un organisme connu. Et voici un cas où une mauvaise analyse peut conduire à des conséquences importantes. Supposons que cet email soit en fait légitime (spoiler : il ne l’est pas), qu’on se trompe sur son analyse et que la mesure de remédiation soit de bloquer tous les expéditeurs de ce domaine. Si on se trompe, l’impact peut être important. Prudence donc, deux vérifications valent mieux qu’une !

Armé de toutes ces trouvailles, on peut raisonnablement statuer que ce mail est malveillant. L’adresse a été usurpée, quelqu’un s’est fait passer pour cette adresse, peut-être à cause de mauvaises configurations d’un ou plusieurs serveurs mails du domaine uptc.edu.co. Cela permet d’envoyer des mails malveillants depuis un domaine connu et potentiellement de confiance. D’après l’analyse des headers, il semble que cette hypothèse soit plus crédible que celle qui consiste à supposer la compromission pure et simple de l’adresse mail de erikajohana. Sinon, pourquoi DKIM et SPF auraient ces valeurs ? Je suis ouvert à toutes critiques sur ce point car je suis pas complètement sûr de l’interprétation que j’en fait. En tout cas, le mail est bien malveillant.

Threat Hunting #

Allons un peu plus loin. Là où la tâche d’un analyste SOC s’arrêterait à la partie précédente, on va faire un peu de threat hunting afin de comprendre un peu mieux les attaquants. Pour cela j’utilise VirusTotal et son mode “Graph” qui est très puissant. Vous devrez créer un compte pour accéder à cette fonctionnalité gratuite.

Mon point de départ est le serveur de delivery, c’est-à-dire celui qui héberge le malware : http[:]//107[.]175.247.199. Il s’agit du serveur vers lequel pointe le lien présent dans le mail. La vue graph nous donne ceci.

On observe plusieurs exécutables (partie gauche). Le fait qu’ils soient en rouge indique qu’il s’agit de fichiers malveillants bien connus. Dans la partie Referrer files on retrouve le mail de départ. Pour les binaires hébergés, 3 ont le nom install.exe. J’ai ensuite déplié le graph pour ces 3 fichiers et après un nettoyage voici ce que j’ai obtenu.

Le graph commence à être un peu complexe mais on peut en tirer pas mal d’informations. Notamment le fait qu’un fichier serveur.exe existe (au centre), on a également son endpoint de téléchargement. On trouve également un fichier malveillant (en rouge) déposé par un des install.exe (Dropped File en haut à droite). Son hash pourrait nous permettre d’identifier des infections dans notre réseau, par exemple.

On trouve également un nom de domaine, ripley.studio qui revient plusieurs fois (ce sont les icons URL en rouge que je n’ai pas affichés). Plusieurs URLs différentes sont requêtées sur ce nom de domaine. De la même manière, il s’agit d’un IOC qu’on pourra utiliser pour identifier des machines compromises. Il y a encore d’autres fichiers déposés par le malware qu’on pourrait analyser, la logique est la même.

Les différents fichiers install.exe sont certainement des versions différentes du malware. On observe que les fichiers contactent parfois les mêmes URLs, parfois des différentes mais avec des patterns similaires. On peut suivre dans le temps l’évolution de cette infrastructure (grâce aux horodatages de primo-analyse, de dernière analyse etc…). Il y aurait encore beaucoup d’information à exploiter. Dans la suite de cet article, je vais me concentrer sur le comportement du fichier install.exe dont le hash est bf7628695c2df7a3020034a065397592a1f8850e59f9a448b555bc1c8c639539.

Analyse de malware #

Loin de moi l’idée de faire de la rétro-ingénierie. Là encore, je vais me baser sur ce que VirusTotal me fournit et éventuellement des rapports de Sandbox disponibles en ligne. Cette approche permet d’ajouter de nouveaux IOCs pour renforcer les capacités de détection, sans avoir besoin de se plonger dans le code assembleur. Il s’agit d’une analyse basique.

L’onglet “Behaviour” de VT nous donne quelques informations. Dans la partie “Shell Commands” on voit une commande encodée qui met le process en dormance pendant 50 secondes. Cela n’est pas signant mais il s’agit d’une technique utilisée pour échapper à certains mécanismes de détection. Dans la partie “Process Tree” on retrouve cette commande louche dans un process tree.

Cela nous permet d’identifier trois processus louches qui sont software.exe, executable.exe et Jzwvix.exe (si on prend une autre version du malware, on trouvera une autre valeur comme Fsaxd.exe). Ils sont tous en relation avec cette commande PS. Un malware cherche souvent à persister sur le système. Le classico-classique est de mettre son malware dans les programmes exécutés à chaque ouverture de session ref. Pour cela, on peut ajouter son binaire dans ces clefs de registres : HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run*. Pour notre malware, on retrouve Jzwvix.exe à cet emplacement. Notez que Jzwvix.exe et install.exe sont les mêmes binaires.

Revenons un moment sur le second graph. On voit au centre une URL qui contient le fichier server.exe (MD5 3056792cfe11d96217fa3626f3ab6a5f). Ce fichier est téléchargé par Jzwvix.exe (voir onglet Behaviour sur VT) depuis la même IP que le loader et qui résoud sur le nom de domaine ripley.studio.

A ce stade, on a une bonne vue d’ensemble de ce à quoi l’infection devrait ressembler dans les grandes lignes.

Ecosystème cybercriminel #

Encore une fois, la vue graph nous aide énormément à traquer les attaquants. Intuitivement, on pourrait s’attendre à retrouver les mêmes IPs et noms de domaine pour le loader et pour le malware final. Cela n’est pas le cas. A la place, on trouve par exemple mywire[.]org qui héberge d’autres fichiers malveillants et qui n’ont à priori rien à voir avec notre infection. Pourquoi ?

Mon interprétation ici est que le RAT (le malware final) est exploité par différents acteurs. Il s’agit d’une organisation commune dans le cybercrime ; un groupe développe le malware puis le vend à d’autres groupes qui l’exploitent, exactement comme un SaaS (Software as a Service). Cet article démontre que des groupes proposent comme service d’installer un ou plusieurs RATs de votre choix chez des victimes : Trend Micro (US) - Water Basilisk Uses New HCrypt Variant to Flood Victims with RAT Payloads. Il est donc plutôt logique de ne pas retouver les mêmes IPs et noms de domaine. Pour les plus curieux, on observe pleins de sous-domaines tels que gh9st.mywire[.]org et d’autres qui suivent un pattern semblable. Je conjecture que ces sous-domaines sont utilisés dans le cadre de campagnes différentes, pour segmenter les différentes entités compromises par le RAT. Néanmoins, je n’ai pas creusé davantage pour le démontrer.

Une autre raison pour laquelle on ne retrouve pas les mêmes IP/noms de domaine est que ces serveurs sont les C2 du RAT et n’ont donc rien à voir avec le loader. Comme expliqué avant, les développeurs du loader et ceux du RAT ne sont probablement pas les mêmes. Par conséquent, ils disposent de leurs propres infrastructures. Une petite digression pour montrer à quel point la vue graph de VT est puissante. Elle permet de collecter des IOCs, de se renseigner sur la menace, de découvrir de nouvelles campagnes d’attaque pour, in fine, améliorer sa posture défensive.

Un dernier pivot #

Maintenant que l’on sait que différentes infrastructures peuvent être utilisées pour distribuer ce RAT, on pourrait rechercher quelques IOCs relatifs à ce malware afin d’être le plus couvrant possible. J’invite le lecteur curieux à continuer mes recherches là où je me suis arrêté, je suis intéressé par vos trouvailles.