Auteur/autrice : psiracusa

Ce qu’il y a de bien avec les antispams c’est qu’on n’a plus besoin d’aller rechercher des malwares sur Internet pour les analyser, on en trouve plein tous les jours dans les quarantaines.

Il y a quelques jours un fichier a attiré mon attention car c’est une extension pas très répandu, un fichier Excel au format XLSB :

Tiens c’est quoi ce truc, ce n’est pas un xlsx, ni un xlsm, ni un xslt mais un xlsb ?

En fait le b c’est pour binary et ça change pas mal de choses.

Je sais que ce fichier est malveillant car il est largement détecté sur VirusTotal mais étonnamment les outils d’analyse de fichiers Office ne détectent rien d’anormal, pas d’OLE, pas de macros.

Au niveau du format de fichier on voit qu’il s’agit d’un Open XML.

En fait il suffit de renommer l’extension xlsb en zip et de dézipper pour comprendre qu’on a bien à faire à des fichiers binaires :

Bon, à ce moment là je me décide d’ouvrir le fichier et j’y découvre une seule feuille avec l’habituel message implorant l’utilisateur à activer les macros :

Bon en fait ce fichier Excel ne contient pas qu’une seule feuille Excel mais un tas d’autres, il suffit d’afficher les feuilles masquées :

Et là mauvaise surprise les feuilles sont vierges :

Bon en fait c’est juste une ruse, les cellules contiennent bien du code mais c’est écrit en blanc sur blanc donc on n’y voit rien, il suffit de changer la couleur du texte, en rouge par exemple pour faire apparaître le code :

Bon maintenant rien qu’avec cette ligne on comprend mieux ce qui se passe :

Un fichier OCX est déposé dans ProgramData et ensuite regsvr32 se charge de l’enregistrer.

Petit rappel sur regvr32.exe qui est une vrai plaie car il permet d’exécuter du code natif, des scriptlets (objets COM de type Javascript) en local, à partir d’une URL distante et se permet le luxe de contourner des solutions comme AppLocker 🙁

Petit exemple avec une scriptlet qui lance un Powershell depuis du Javascript :

regsvr32 /u /s /n /i:stuff.txt scrobj.dll

stuff.txt :

<?XML version="1.0"?>
<scriptlet>
<registration
progid="Pentest"
classid="{10001111-0000-0000-0000-0000FEEDACDC}" >
<script language="JScript">
<![CDATA[
var r = new ActiveXObject("WScript.Shell").Run("powershell -noe -nop -c write-host Boo!");
]]>
</script>
</registration>
</scriptlet>

Dans le cadre d’un CTF, j’ai eu à analyser un « maldoc », un document Word malveillant.

Vous pouvez télécharger ce maldoc « 49b367ac261a722a7c2bbbc328c32545 » sur le (très bon) site : https://cyberdefenders.org/labs/76

Tout d’abord comment savoir qu’il s’agit d’un document Office ?

Le plus simple est d’utiliser la commande file sous Linux (il existe même une version compilée pour Windows), à défaut vous pouvez ouvrir le fichier dans un éditeur hexadécimal et comparer les premières valeurs avec ce tableau (document de référence, https://www.sstic.org/media/SSTIC2021/SSTIC-actes/oletools/SSTIC2021-Slides-oletools-lagadec.pdf)

Dans notre cas on a ceci :

C’est un fichier OLE (Word/Excel/PPT 97).

S’agissant d’un fichier OLE, je vous conseille l’outil « olevba » (https://github.com/decalage2/oletools) qui va nous être d’une grande aide pour désosser ce fichier à la recherche des macros et mots-clefs suspicieux sans pour autant l’exécuter.

Voici les éléments le plus intéressant relevés par olevba, à la lecture du code des macros il semble y avoir :

• Un drop d’un fichier maintool.js dans le dossier AppData de l’utilisateur
• Exécution de ce fichier maintool.js avec la valeur EzZETcSXyKAdF_e5I2i1 en paramètre

On peut confirmer cette hypothèse en exécutant la macro dans une sandbox (en local ou sur Internet), dans un Word en vrai mais en mode debug (little dangerous) ou bien via un parseur et émulateur de code VBA (pas besoin de Word dans ce cas), par exemple avec ViperMonkey (https://github.com/decalage2/ViperMonkey)

Testons donc avec ViperMonkey (dans mon cas il tourne dans un container docker) :

On voit bien dans le flot d’exécution le drop d’un fichier (« Dropped File Hash »).

On va maintenant s’intéresser à ce fichier droppé, le fichier maintool.js.

Pour le récupérer j’ai choisi la méthode via la sanbox sur Internet via « App Any Run », en voici une exécution (https://app.any.run/tasks/5840a1fa-9ad9-4c9e-963a-7bc5b6fa3eff/)

On voit à droite l’exécution du fichier js via la commande native Windows WScript.exe.

Pour récupérer le fichier maintool.js, il suffit de cliquer sur « More Info » puis « Download » (il vous faut un compte) :

Le fichier js est compressé dans un zip avec un mot de passe (« infected »).

Comme d’habitude les fichier js sont obfusqués :

Dans un premier temps on va arranger tout ça (au sens faciliter la lecture du code) avec CyberChef et son Javascript Beautify : (https://gchq.github.io/CyberChef/#recipe=JavaScript_Beautify(‘%5C%5Ct’,’Auto’,true,true) :

On voit que ce Javascript a besoin d’un argument, sûrement la clef pour décoder/déchiffrer le vrai code malveillant.

J’ai donc remplacer la variable ssWZ par la valeur vu au début avec olevba (EzZETcSXyKAdF_e5I2i1) et j’ai remplacé l’appel à la fonction eval() par une sortie console via WScript.Echo :

Maintenant je n’ai plus qu’à lancer l’exécution avec cscript.exe sans grand risque (plus d’eval) afin de récupérer le code désofusqué :

Les choses sont plus claires maintenant, on voit les URL cibles, les commandes exécutées, les net view/share/add administrator, etc…