Le Blaireau de Wall Street

Partie 1 - Packer

La première étape pour résoudre ce challenge est d'inverser le mécanisme de packing. Le packer utilisé est upx, ce qui peut être détecté automatiquement avec un outil de rétro-ingénierie configuré, ou bien à l'aide de recherche ou connaissances personnelles. L'utilisation de l'option -d permettra d'inverser le mécanisme et ainsi d'avoir un code plus propre pour la suite des étapes.

Seconde partie - Rétro-ingénierie

Pour cette section, nous allons répondre aux différentes
questions posées aux candidats en expliquant le raisonnement
attendu.

Dans un premier temps, il est attendu d'utiliser un outil de
rétro-ingénierie, par exemple, Ghidra.

Critères d’activation du virus

Il convient de trouver 3 conditions d'activation pour ce virus :

1. Que le système soit un Windows Server 2025.
   Nous pouvons voir un appel à la fonction
   void OIlIllIIllIllIO(void), contenant notamment la variable
   suivante _OSVERSIONINFOA local_a8;, qui est une structure
   donnant des informations sur la machine. Cela laisse penser à
   une vérification concernant ceci, d'autant plus avec l'appel à
   la fonction GetVersionExA.

En regardant le contenu de la fonction real_label29(), nous
pouvons voir la vérification suivante :
in_stack_000000ba != '\x01 , ce qui permet de savoir si la
machine est un poste de travail ou un serveur. Dans notre cas,
la fonction retourne la valeur TRUE s'il s'agit d'un serveur.

1. Que le processus ServerManager.exe soit lancé.
   En effet, on remarque un premier appel à une fonction :
   uVar2 = OIlIIlIIllIllIO(L"ServerManager.exe");
   En étudiant le contenu de cette fonction, nous pouvons voir des
   appels à des fonctions de la Windows API.
   Nous pouvons notamment voir un premier appel à une fonction
   CreateToolHelp32Snapshot qui réalise une snapshot des services
   tournants sur le système.
   Nous remarquons une boucle while itérant à partir du premier
   processus trouvé grâce à la fonction Process32FirstW.
   Nous voyons aussi l'existence d'une condition permettant de
   retourner la valeur
   TRUE : iVar1 = _wcsicmp(local_23c,param_1);.
   La variable param_1 est passée en argument et fait référence au
   premier appel de fonction observé ci-dessus, et contient donc
   ServerManager.exe.
   Il est donc nécessaire que ce processus soit lancé.

2. Qu'une requête GET vers l'URL moneymustbefunny.xyz soit
   réussie.
   Nous remarquons l'existence de la variable
   lVar1 = InternetOpenA("SimpleGET",1,0,0,0); qui initialise
   l'utilisation d'une application des fonctions WinINet.
   Nous pouvons voir qu'une connexion entre la machine et le
   serveur est établie avec la fonction InternetOpenUrlA grâce
   à la variable lVar1. Ensuite, en suivant le symbole
   real_label29(), nous arrivons dans une nouvelle fonction
   qui utilise HttpQueryInfoA() que nous pouvons comprendre
   comme une requête effectuée vers l'URL vue au-dessus.
   Puis, le header de la réponse est analysé, et que le code
   retour HTTP est comparé avec la valeur 200 (OK).

Nous retrouvons ces conditions dans la fonction recog appelée
dans main :

Nous voyons l'utilisation de la fonction OIllIlIIllIIlIO
qui, si l'on regarde son contenu, vérifie l'accès à l'URL
cherchée.

Algorithme utilisé pour chiffrer les données

Après quelques recherches pour trouver la fonction intéressante
OlIIllIIllIllIO, nous pouvons voir l'appel suivant :
CryptAcquireContextA(&local_38,(LPCSTR)0x0,"Microsoft Enhanced RSA and AES Cryptographic Provider",0x18,0xf0000000);
Nous pouvons voir qu'il s'agit de la création d'un contexte
pour l'utilisation de la CryptAPI de Windows, pour les clés
RSA et AES.

Nous remarquons ensuite la fonction
CryptGenKey(local_38,0x6610,1,&local_30);, et nous pouvons
voir que l'identifiant ALG_ID numéro 0x6610 correspond à
l'utilisation de l'algorithme CALG_AES_256, soit AES-256.

Les données sont-elles exfiltrées ?

Nous pouvons voir l'appel à la fonction OIllIlIIllIIllO
prenant comme argument un chemin vers un fichier de compression
files.zip.

En allant dans la fonction, nous pouvons aussi voir l'appel à
la fonction InternetOpenA("WebDAVUploader",1,0,0,0);
utilisant l'API WinINet, appelant l'agent WebDAVUploader
permettant notamment de gérer des fichiers sur un serveur
distant.

En suivant le symbole real_symbol81, nous voyons la chaine
de caractères suivante /#/webdav/save/files.zip se
concaténant avec la chaine de caractères passée en paramètres
contenant whalesaregonnnasaveus.xyz (retrouvée grâce à la
référence : puVar4 = &DAT_14000b42c;), ce qui nous donne un
lien vers lequel les données sont exfiltrées.

Quelle est l'adresse utilisée pour exfiltrer les données ?

Nous avons ainsi pu voir que l'adresse d'exfiltration est
https://whalesaregonnnasaveus.xyz/#/webdav/save/files.zip.

Les données sont telles déchiffrables ?

Nous pouvons trouver la présence de la variable BVar1 dans le
real_label72 contenant en clair une clé publique RSA.
Nous voyons aussi la fonction OlllIllIlIIIlIO utilisant
cette variable. L'utilisation de la fonction CryptEncrypt
avec la variable pbData contenant la clé AES (par memcpy)
et local_48 notre clé RSA nous fait comprendre que celle-ci
est chiffrée avec l'algorithme RSA, avant d'être exfiltrée.
Les variables sont libérées et le tout est nettoyé, et la clé
privée RSA n'est pas dans le binaire. Il n'est donc pas possible
de déchiffrer les données.