Catégorie : MALWARE

Ce post est une toute petite introduction à l’EDR ELK Security (de la suite Elastic) et un test rapide de détection des beacons standard Cobalt Strike.

Il est possible de tester toutes les fonctionnalités de la suite Elastic y compris celles de sécurité comme le Machine Learning et son EDR pour 30 jours alors let’s go !

Pleins de tutos fourmillent sur Internet, ci-joint quelques liens que j’ai utilisé pour monter ce LAB en VM :

A noter qu’Elastic vous permet aussi de tester leur solution sur une instance Cloud.

• https://techviewleo.com/install-elastic-stack-7-elk-on-debian/
• https://www.stefan-hechler.de/it/elastic-guide-install-the-easy-way-fleet-management/
• https://www.youtube.com/watch?v=11PWoDIc10I

Voici la configuration de mon LAB au niveau de l’EDR ELK :

Comme tous les EDR vous pouvez choisir d’être en mode Détection uniquement ou en mode Détection et Prévention.

J’ai d’abord choisi de tester le mode Détection uniquement :

J’ai ensuite activé un maximum de Rules :

Ensuite j’ai déployé l’agent EDR sur une machine Windows 10 :

Du côté de la VM Windows 10, on note la présence de l’EDR ELK dans les services :

Afin de ne pas bloquer les beacons de base Cobalt Strike j’ai volontairement désactivé l’antivirus, dans mon cas Windows Defender :

OK maintenant on prêt pour les tests.

Je lance mon team server Cobalt Strike et je génère un fichier malveillant de type HTA que je dépose sur la VM Windows 10 victime :

Maintenant je clique sur evil.hta et je passe du côté de l’EDR pour voir ce qu’il se passe : la menace est bien détectée, on peut voir les détails de la chaine d’exécution :

Vu que je suis en mode Detection only la connexion entre l’agent Cobalt Strike et mon TeamServer n’est pas coupée, je peux donc lancer des commandes à distance comme par exemple lister les processus de la machine Windows 10 :

Côté EDR je n’ai cependant pas noté de détection supplémentaire liée à cette action..

Faisons un autre test, cette fois en passant en mode Detection and Prevention avec notification de l’utilisateur :

Côté Cobalt Strike je génère cette-fois un beacon http sous forme d’exécutable (artifact.exe) :

Je dépose ensuite cet exécutable sur la VM Windows 10 et pareil je le lance et j’observe, on obtient une nouvelle alerte :

Et cette fois le beacon Cobalt Strike est stoppé dans sa course grâce à la prévention, côté utilisateur on a bien une notification :

Ce qui intéressant avec ce type de LAB c’est qu’on peut s’en servir comme sandbox pour une analyse dynamique des malwares et observer les feux d’artifice des détections 🙂

Voila, ceci conclut cette petite introduction à l’EDR ELK Security.

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…