Investigation Phishing - OSINT

EnzoLe 19 septembre 2023

I – Le contexte de notre enquête cyber

Après un week-end à la montagne, l’équipe du CERT d’AlgoSecure reçoit un mail intrigant de la part d’un des commerciaux. Ce dernier a reçu le mail de phishing présenté ci-dessous avec un lien permettant de télécharger un fichier. De prime abord, celui-ci ressemble à un tableur Excel.

l'email de phishing reçu par AlgoSecure

Au cours de cet article, nous allons décrire la démarche d’analyse qui a été réalisée pour découvrir l’objectif de ce mail de phishing. Dans un premier temps, une phase de retro-ingénierie sera effectuée pour découvrir qui se qui se cache derrière ce document Excel. Dans un second temps, une investigation d’OSINT sera menée afin de retrouver des informations sur l’attaquant.

II - Méthodologie d’analyse de rétro-ingénierie et d’OSINT

A. Partie rétro-ingénierie

La première étape est de se procurer le fichier supposé malveillant. Il se trouve que le lien fourni dans le mail télécharge un fichier avec un extension au format XLL, ce qui ne correspond pas exactement à un tableur Excel. Ce format représente une DLL utilisée par Excel, aussi connu sous la forme d’add-ins.Elle contient des fonctions supplémentaires utilisées par le tableur.

Le téléchargement de ce fichier passe par une instance Wordpress qui sert vraisemblablement de plateforme de stockage pour des fichiers malveillants. Cette dernière semble avoir été compromise par les attaquants.

https[:]//fendtoldtimer[.]com/wp-content/uploads/2023/02/Microsoft/Offre%20Mars%202023[.]xll

A.1 – Analyse du fichier XLL

Analyse du fichier XLL malveillant issu de la plateforme wordpress compromise

L’utilitaire Binwalk https://github.com/ReFirmLabs/binwalk nous montre les fichiers contenus dans le binaire. L’option -e nous permet d’extraire ces fichiers pour continuer l’analyse :

Extraction des fichiers contenus dans le XLL avec Binwalk

Parmi les fichiers extraits, 2 sont des archives au format 7z, les deux autres sont des exécutables :

Analyse des archives 7z LZMA contenues dans le XLL

Une analyse des chaînes de caractères sur le binaire 73AD8 permet de découvrir que c’est une DLL ExcelDna, plus précisément ExcelDna.Integration.dll après recherche de son md5. Le projet Excel-DNA a pour but de faciliter le développement de nouvelles fonctionnalités comme les add-ins pour Excel avec l’utilisation du .NET.

Concernant le second fichier 83C40, il s’agit d’un exécutable .NET compilé avec Mono. La suite de l’investigation sera mise en œuvre à l’aide de dnSpy.

Analyse de l'exécutable .NET compilé avec Mono

Cet outil permet d’obtenir le code source de l’application en .NET. Dans les analyses qui vont suivre, nous aurons affaire au langage C#. De plus, dnSpy offre la possibilité de débuguer ce code, ce qui nous donne la faculté d’exécuter le code et de placer des breakpoints. Cette opération permet de stopper l’exécution d’un programme sur une instruction spécifique. Ensuite, les variables du programme pourront être analysées pour vérifier leur contenu par exemple.

A.2 – Analyse du premier EXE

L’arborescence du code ne nous donne pas beaucoup d’information sur ce que fait le programme. De plus, les noms de fonctions sont pour la majorité des chaînes de caractère aléatoire. Parmi tous ces éléments, la classe EventLogFileFactory contient des éléments qui méritent notre attention.

Désassemblage de la fonction EventLogFileFactory

Ces fonctions sont assez longues et possèdent beaucoup de code inutile afin de faire perdre du temps aux analystes. Par exemple, X7H6MEYIDOEI, dont la seule utilité pour l’attaquant est la fonction WriteAllBytes(), se retrouve noyée au milieu d’autres instructions réalisant des conditions qui ne sont jamais validées.

Comment l'attaquant noie son code au milieu d'instructions inutiles

Dans l’ensemble des fonctions que dnSpy nous a permis de retrouver, la fonction AutoOpen() est particulièrement intéressante comme le montre la capture ci-dessous :

La fonction AutoOpen génère un exécutable oaiAlVs.exe

La variable flag étant toujours vraie, le code va appeler la fonction BEB128 avec la très longue chaîne de caractère text2. Cette fonction est simplement un wrapper (fonction qui appelle une autre fonction pour en faciliter l’usage) pour la fonction FromBase64String en C#. Elle permet de décoder la variable text2 qui est en base64.

Le code était préalablement encodé en base64

Le résultat de la fonction BEB128 est écrit dans le fichier oaiAlVs.exe situé au niveau du dossier C:\Windows\Temp\ comme le montre le code de la fonction X7H6MEYIDOEI. Nous avons à présent un nouveau binaire à explorer. Comme le précédent, il est de nouveau écrit en .NET. Pour les étapes suivantes de l’analyse, tous les binaires sont également écrit en dans ce même langage.

A.3 – Analyse de oaiAlVs.exe

Désassemblage du binaire oaiAlVs.exe

Nous retrouvons plusieurs fonctions avec le format XOQ00[1-7] :

Analyse des fonctions XOQ00

La fonction XOQ001 traite une longue chaine de caractère

En particulier la première fonction XOQ001 qui commence par récupérer l’objet CLC02. Celui-ci est en réalité une longue chaîne de caractères qui semble être incompréhensible à première vue. Mais par la suite, le code effectue différentes étapes de désobfuscation pour retrouver une forme intelligible.

Le code est désobfusqué puis placé dans l'objet CLC02

Nous plaçons un breakpoint sur le retour de la fonction pour récupérer le contenu de la variable UUUU6. Ce dernier nous évite d’avoir à écrire un bout de code pour retrouver le format décodé de l’objet CLC02. Nous obtenons ainsi la charge utile décodée en mémoire.

Plusieurs éléments nous indiquent que nous sommes face à un nouvel exécutable avec les premiers « bytes » qui correspondent à MZ, puis avec la chaîne de caractères « This program cannot be run in DOS mode ». Ces éléments sont caractéristiques d’un fichier exécutable communément appelé PE (Portable Executable).

La charge utile correspond à un portable exécutable PE

A.4 – Analyse de CardGame.exe

Analyse du portable exécutable CardGame.exe

Nous ré-ouvrons ce binaire a l’aide de dnSpy tout en constatant que les fonctions possèdent des noms étranges comme précédemment. Identification avec dnSpy d'une fonction AddContext

La fonction AddContext attire notre attention car elle permettrait de décoder une ressource. Cette action est réalisée à l’aide des fonctions IIII26, III24, LabelEdit et LabelTextAdd. Le résultat obtenu est ensuite exécuté en mémoire.

Analyse de la fonction AddContext

Pour continuer, nous devons d’abord retrouver les arguments utilisés pour appeler la fonction AddContext. Pour cela, nous retournons dans le binaire précédent pour récupérer l’appel à cette fonction.

La valeur AddContext est identifiée dans la fonction XOQ006 :

On retrouve l'appel à AddContext dans la fonction XOQ006

Ensuite, XOQ006 fait appel à XOQ007 qui fait elle-même appel à KCWSJK :

En suivant les appels de fonction on arrive à la fonction KCWSJK et 2 variables intéressantes

En explorant la fonction KCWSJK, nous constatons qu’il y a encore une fois, beaucoup de code inutile. Cependant, la fin de celui-ci contient la partie intéressante avec 2 variables xxx et xxx2 qui sont retournées sous la forme d’un tableau.

De tout cela nous déduisons la méthode d'appel à AddContext

Nous pouvons ainsi déduire que l’appel à la fonction AddContext est fait de la façon suivante :

AddContext("PaEUiHUbE", "LuH", "Assignment_1")

AddContext commence par récupérer une ressource dans Assignment_1 qui est le binaire appelant.

AddContext récupère une ressource dans le binaire appelant

En effet, nous retrouvons bien des images dans les ressources du binaire précédent. Parmi ces images, nous avons bien l’image PaEUiHUbE. En ce qui concerne les deux images suivantes, elles représentent une femme dévêtue. Dans le cadre de cet article, elles ont été remplacées par des chats.

Une image intéressant parmi 3 est identifiée

Cette dernière est sûrement une forme de distraction mise en place par les développeurs de ce malware. Mais il en faut plus pour empêcher le CERT d’AlgoSecure de continuer sa mission :). Si nous revenons à l’image PaEUiHUbE, nous constatons qu’elle ne représente pas grand-chose dans sa forme originelle.

Il nous est maintenant possible de réécrire un bout de code déchiffrant l’image en la copiant directement de dnSpy et en reprenant les différentes fonctions de stéganographie (art consistant à cacher de l’information). Le code présenté ci-dessous permet d’écrire le résultat de l’image une fois décodé :

Un peu de stéganographie permet de récupérer le code suivant dans image PaEUiHUbE

Le code commenté est celui utilisé par l’attaquant. Pour le nôtre, nous récupérons simplement l’image que nous avons extraite. Elle est envoyée dans les fonctions III14, LabelEdit et LabelTextAdd que nous avons simplement repris depuis dnSpy. Finalement le résultat est écrit dans le fichier 4.exe. Ce nouveau binaire est envoyé dans dnSpy pour poursuivre l’analyse.

A.5 – Analyse de 4.exe

Analyse du portable exécutable CardGame.exe

À l’ouverture du fichier, nous constatons que le code source du programme semble packé. NDLR : le terme packé fait référence à une méthode d’obfuscation qui a pour but de rendre un programme plus difficile à analyser dans les étapes de rétro-ingénierie qui suivront une compromission. Cela peut également servir à modifier le fichier malveillant pour passer outre les mécanismes de détection qui utilisent des signatures connues comme les antivirus. Cette étape peut intervenir avant ou après la compilation du code.

Dans le cas présent, l’étape d’obfuscation a été réalisée avant la compilation. Nous pouvons constater que les noms de fonction et de variables sont une suite de caractères unicode compatible seulement partiellement avec dnSpy.

Après quelques recherches, il s’avère que le code source a été packé avec ConfuserEx https://github.com/yck1509/ConfuserEx. L’utilitaire de4dot-cex disponible sur github https://github.com/ViRb3/de4dot-cex nous permet d’unpacker le programme et de retrouver le code source dans un format lisible. Cela est rendu possible car une configuration par défaut a été utilisée avec ConfuserEx.

L'utilitaire de4dot-cex permet de dépacker l'exécutable obfusqué avec confuserEx

Nous obtenons ainsi une version nettoyée de 4.exe, le programme est ainsi beaucoup plus facile à lire dans dnSpy.

La version dépackée est, encore une fois, désassemblée avec dnSpy

Les fonctions smethod_X sont pour la plupart des wrappers vers d’autres fonctions liées à l’API de Windows.

Si nous regardons du côté des chaînes de caractères présentes dans le binaire :

Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableBehaviorMonitoring $true
DisableBlockAtFirstSeen
Set-MpPreference -DisableBlockAtFirstSeen $true
DisableIOAVProtection
DisablePrivacyMode
SignatureDisableUpdateOnStartupWithoutEngine
DisableArchiveScanning
Set-MpPreference -DisableArchiveScanning $true
DisableIntrusionPreventionSystem
DisableScriptScanning
SubmitSamplesConsent
MAPSReporting
HighThreatDefaultAction
Set-MpPreference -HighThreatDefaultAction 6 -Force
ModerateThreatDefaultAction
Set-MpPreference -ModerateThreatDefaultAction 6
LowThreatDefaultAction
SevereThreatDefaultAction
Set-MpPreference -SevereThreatDefaultAction 6
Set-MpPreference -LowThreatDefaultAction 6
Set-MpPreference -MAPSReporting 0
Set-MpPreference -SubmitSamplesConsent 2
Set-MpPreference -DisableScriptScanning $true
Set-MpPreference -DisableIntrusionPreventionSystem $true
Set-MpPreference -SignatureDisableUpdateOnStartupWithoutEngine $true
Set-MpPreference -DisablePrivacyMode $true
Set-MpPreference -DisableIOAVProtection $true

Nous pouvons constater qu’en plus de l’obfuscation du code avec ConfuserEx, les attaquants ont pris la peine d’ajouter des commandes qui ont pour objectifs de désactiver les solutions de sécurité présentent sur la machine ayant ouverte le premier fichier au format XLL.

Ensuite, les vérifications suivantes sont mises en place par le code pour savoir si l’exécution est faite dans une machine virtuelle :

Les attaquants ont mis en place des commandes d'anti debugging pour empêcher un travail de reverse engineering dans une machine virtuelle

Cette méthode est aussi connue sous le nom d’anti-debugging. Elle consiste à empêcher les équipes défensives de réaliser une analyse dynamique dans une sandbox à l’aide d’une machine virtuelle. Les sandboxs sont des environnements utilisés dans le cadre de l’analyse de fichiers malveillants dans le but d’ observer leurs comportements. Ici, cela n’a eu aucun effet comme nous observons le fichier de manière statique.

En revenant à l’analyse du code, nous pouvons observer qu’une variable r3Fk est utilisée dans la fonction smethod_ chargée dans la variable Class10.byte_0 .

Nous identifions une variable r3Fk

Cette dernière fait en réalité référence à une ressource présente dans le binaire. Nous en retrouvons plusieurs, dont deux images « DanYRa » et « UAivcpnOet » qui n’attirent pas notre regard cette fois-ci, ainsi qu’un blob de données binaire « r3Fk » :

Cette variable est présente dans 2 ressources images et un blob de données du binaire

r3Fk sert  à stocker des données utilisées par d'autres fonctions

smethod_ se charge de récupérer le fichier r3Fk dans les ressources. Ensuite nous avons les fonctions smethod_2 et smethod_1 qui s’occupent de déchiffrer les données contenues dans r3Fk. Tout en faisant appel à d’autres fonctions smethod.

r3Fk est utilisée par la fonction smethod pour générer un dernier exécutable

Le code suivant permet de déchiffrer simplement la ressource r3Fk et de la mettre dans le fichier 5.exe qui correspond au dernier binaire que nous analyserons :

Ce dernier exécutable est nommé 5.exe

A.6 – Analyse de 5.exe

Nous obtenons ainsi le fichier 5.exe. Ce fichier est un password stealer copié depuis https://github.com/L1ghtM4n/DynamicStealer. En observant sa configuration, nous retrouvons un jeton pour se connecter à une conversation Telegram :

5.exe est un password stealer envoyant ses données à un utilisateur telegram dont l'ID est 5781881180

Les mots de passe volés sont envoyés par message privé à l’utilisateur ayant pour ID 5781881180 à l’aide de celui-ci. Cependant cette API étant limitée, il n’est pas possible de consulter les messages qui sont envoyés sur cette conversation.

Voici en résumé le fonctionnement du malware depuis l’hameçonnage jusqu’au téléchargement de la DLL en charge de subtiliser les mots de passe de la victime :

Schéma du fonctionnement général du malware après décompilation via l'équipe de Reverse Engineering

Partie OSINT (Open Source Intelligence)

À l’aide des informations récupérées précédemment, notre analyse s’achevait sur la découverte de la méthode et de la destination des données volées à l’aide du "password stealer".

Nos investigations OSINT commencent pour profiler l'utilisateur telegram 5781881180 alias thesilentcoder

Et c’est à ce stade de notre investigation que la partie OSINT peut débuter. En effet, l’histoire n’est pas encore terminée.

L'équipe OSINT prend le relais de l'équipe CERT / Reverse Engineering d'AlgoSecure

Nous avons été en mesure d’extraire des informations concernant la destination des mots de passe volés. Il se trouve que ceux-ci sont envoyés à l’utilisateur thesilentcoder sur Telegram.

Il n'y a rien de probant sur le compte Telegram de thesilentcoder

Cependant, nous n’avons rien trouvé de probant sur son profil. Nous avons fait le choix de poursuivre nos recherches sur d’autres réseaux sociaux. Pour commencer, nous décidons de faire une simple recherche Google à l’aide de son nom d’utilisateur.

Une recherche google sur thesilentcode permet de trouver une chaine Youtube

Nous remarquons que celui-ci est présent dans la description d’une vidéo. Celle-ci est postée sur la chaîne de SILENT CODER STORE. Le titre de la vidéo ne nous surprends guère et colle au profil d’un attaquant de ce style : Spamming : How to send email INBOX 100%.

Cette chaîne YouTube nous apporte un point de pivot intéressant puisque nous détenons un nouveau mot-clé sur lequel s’appuyer : SILENT CODER STORE. Comme nous savons que l’attaquant est présent sur Telegram, notre premier réflexe a été d’y effectuer une recherche.

Social Media Intelligence la chaîne Youtube nous permet de découvrir un nouveau mot clé associé à l'attaquant : silent coder store

Nous remarquons qu’il existe effectivement un groupe du même nom. Cela dit, rien ne prouve que ce groupe et l’attaquant soient liés. L’hypothèse se précise lorsque nous trouvons certains messages pouvant faire office de preuve.

On retrouve sur le groupe telegram l'exploit xll et la chaîne Youtube

En effet, nous remarquons que l’utilisateur CRUISER, fondateur du groupe que nous présumons être l’attaquant, y poste régulièrement. Ces deux messages montrent d’une part le lien avec sa chaîne YouTube (photo de gauche) et d’autre part le lien avec l’exploit XLL utilisé dans son e-mail de phishing (photo de droite). Le lien entre les deux semble possible et l’hypothèse nous semble valide.

Par ailleurs, un autre message se trouve être intéressant. Il s’agit d’une photo postée par l’attaquant présumé. Nous pouvons l’apercevoir dans un lieu accompagné de son équipement informatique.

Analyse du portable exécutable CardGame.exe

Avant de commencer le processus de GEOINT, nous tenions à confirmer que l’homme sur cette photo est hypothétiquement notre attaquant. Pour ce faire, nous regardons les autres messages qu’il poste dans le groupe. Dans deux d’entre eux, nous notons clairement l’équipement qu’il utilise : un iPhone et un MacBook Air.

Match entre la photo du café / restaurant et le matériel de l'utilisateur Cruiser

Il se trouve que ceux-ci se retrouvent également sur sa photo, nous amenant à alimenter notre hypothèse.

Au niveau de sa géolocalisation, plusieurs indices intéressants sont présent sur la photo :

  • Le décors (piliers en bois, plantes suspendues)
  • Le mobilier (chaises avec un dossier noir et des pieds en bois ainsi que les tables en bois)
  • La chicha sur le côté gauche

Ce sont ces éléments qui nous ont permis, avec l’aide de Yandex et de Google Lens, de retrouver le lieu dans lequel la photo a été prise.

GEOINT identification du lieu grâce à Google et Yandex

Deux photos nous permettent de confirmer que l’endroit que nous avons trouvé est le bon. D’un côté, nous retrouvons le même décor et le même mobilier (photo de droite). Cela se remarque par la présence du pilier en bois ainsi que par le modèle de chaise similaire. De l’autre côté, nous retrouvons une chicha (photo du bas) qui prouve que ce lieu en met à disposition.

Page Tripadvisor du restaurant l'Orientale à Dakar au Sénégal

Notre attaquant potentiel se trouvait donc à L’Orientale, restaurant situé à Dakar au Sénégal. Nous supposons que celui-ci est probablement originaire du même endroit.

Cette partie nous a permis de démontrer que l’OSINT est une composante essentielle lors d’une investigation. Grâce à celle-ci, nous avons pu récolter des preuves permettant de retrouver la trace du potentiel attaquant. Aussi, nous avons réussi à trouver son lieu de résidence potentiel.

III - Conclusion

Au cours de cet article, nous avons pu mettre en avant différentes techniques de rétro-ingénierie en partant d’un simple mail de phishing pour arriver à retrouver le binaire final qui était imbriqué dans plusieurs programmes. Ce dernier permet de voler les mots de passe des victimes et de les envoyer dans un chat privé sur Telegram à un utilisateur.

Quant à la seconde partie, elle a pu mettre en avant plusieurs techniques d’OSINT, essentiellement basées sur du SOCMINT et du GEOINT. Celles-ci nous ont permis de retrouver la trace potentielle de l’attaquant sur les réseaux sociaux. De là, nous avons pu récolter différentes preuves de son implication dans cette campagne de phishing, pour finir par le géolocaliser.

En ce qui concerne l’utilisation du fichier XLL, c’est une technique de plus en plus répandue pour les mails d’hameçonnage. Cela fait suite à la décision de Microsoft de désactiver l’exécution des macros par défaut au sein de la suite Office. Les récents articles d’analyse des équipes de Cisco, Talos et d’HP nous ont inspirés dans le cadre de cette investigation.

Il est également important de noter la réaction des équipes commerciales lors de la réception de ce mail de phishing. Le bon réflexe est d’avoir averti directement les équipes de sécurité avant d’effectuer toute autre action. Ceci a permis de prévenir l’ensemble des collaborateurs que nous étions face à une campagne de phishing ciblée et de rester vigilant face aux nombreux mails que nous recevons chaque jour.

Si vous souhaitez plus d’information sur le fonctionnement des campagnes de phishing, cet article de blog est susceptible de vous intéresser : Le phishing : comprendre les mécanismes pour mieux s’en protéger.

De la même façon, si vous avez besoin d’un accompagnement dans le cadre d’une réponse à incident ou besoin d’effectuer des opérations d’OSINT sur le périmètre de votre entreprise, nous sommes disponibles pour en discuter.

You've enabled "Do Not Track" in your browser, we respect that choice and don't track your visit on our website.