Investigation Phishing - OSINT

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.

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

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 :

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

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.

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.

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.

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 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 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

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

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.

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).

A.4 – Analyse de 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.

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.

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 :

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

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.

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.

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.

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é :

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

À 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.

Nous obtenons ainsi une version nettoyée de 4.exe, le programme est ainsi beaucoup plus facile à lire dans 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 :

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 .

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 » :

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.

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 :

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 :

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 :

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".

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.