Intrusion et recherche
Un peu de contexte !
Il faut savoir que je suis actuellement étudiant à Guardia, qui est une école de cyber-sécurité, la manière d’enseigner ici nous amène souvent à travailler en groupe (pédagogie par projet).
Dans le cadre d’un projet pour l’école, nous étions donc amenés à mettre en place des serveurs Web. Il était possible de le déployer en local, mais pour rendre les choses un peu plus fun et plus concrètes, j’ai décidé de mettre en place des VPS Google Cloud pour mon groupe.
Comme mes camarades n’étaient pas encore familier avec tout l’environnement cloud au moment de ce projet, et pour faciliter les choses, j’ai décidé de désactiver l’authentification par clée SSH qui est là par défaut et de mettre une simple connexion par mot de passe pour que mes camarades puissent se connecter facilement.
L’erreur de débutant
Après avoir donc mis en place plusieurs VPS, j’ai fait face à une des erreurs les plus classiques et rageante en informatique : les mots de passes faibles.
En effet après le paramétrage des 3 VMs, j’ai reçu une alerte de mon hébergeur comme quoi une des VMs avait une activitée suspecte. Étant en week-end (et plutôt occupé à ce moment là) j’ai simplement coupé la VM et remis le problème à plus tard.
Quelques jours plus tard j’ai commencé mon investigation, et effectivement les logs montrent plus de 4000 tentatives de connexion en SSH. Et certaines ont réussi ! Ma VM était donc compromise.
J’ai aussi remarqué un processus qui consommait 100% de ma capacité CPU depuis 3 jours et rendait la Vm inutilisable, en plus d’une centaine de connexions ouvertes en SSH : impossible de faire quoi que ce soit avec de telles conditions.
Le but est donc ici de stopper toute activité non-désirée sur la machine.
J’ai donc procédé comme ceci :
- Création d’une image instantanée de la VM (Si jamais on perds des données on pourra toujours examiner cette image en offline)
- J’ai ensuite restreint les règles de pare-feu au minimum pour bloquer les connexions entrantes et sortantes qui monopolisaient une grande partie de la RAM.
- Puis j’ai procédé à l’arrêt du programme malveillant avec killall [pid] -9 pour forcer l’arrêt.
- Enfin, j’ai redémarré la machine pour stopper toutes les connexions existantes (le pare-feu empêche seulement — dans ce cas— les nouvelles connexions).
- Après que la machine ait redémarré j’ai identifié le fichier malveillant avec ClamAv (il s’agissait d’un simple miner de crypto-monnaies).
- Pour finir j’ai désactivé l’authentification par mot de passes et supprimé et nettoyé les tâches cron pour éviter une nouvelle contamination.
La revanche
Oui, je me suis fait avoir comme un bleu sur ce coup là ! Mais c’est comme ça qu’on apprend !
Récupérer des informations
Après avoir vu tout ça je me suis mis en tête de mettre en place un serveur ‘honeypot’ pour pouvoir mieux comprendre et étudier l’origine et le mode opératoire de ces attaques : en effet, les données que j’avais pour ma première attaque étaient minces (une ip localisant au Vietnam et un executable ELF de 4.6Mo que je n’avais vraiment pas (mais alors VRAIMENT PAS) envie de reverse.
Pour obtenir plus d’informations sur ces attaques j’ai donc utilisé Cowrie qui est un honeypot basique ssh (et telnet) d’interaction moyenne permettant d’attirer les pirates sur un serveur qui paraît non-sécurisé, d’observer les commandes et les fichiers qui sont téléchargés (en plus des fonctionnalités basiques des logs qui enregistrent l’ip de connexion et les tentatives).
Et au bout d’une trentaine de minutes une connexion avec root:root et un utilisateur avec l’ip 209.XX.XX.170 (USA) dépose un fichier AB4g5.sh et tente de l’exécuter.
Analyse de la menace
Quand on examine le fichier téléchargé, on peut voir qu’il s’agit d’un fichier bash un peu barbare au premier abord. On remarque en regardant d’un rapide coup d’oeil un wget vers la même adresse ip pour téléchager un fichier.
Les seules différences entres les lignes du script sont l’extension du fichier (.x86, .mips, .mpsl etc…). Ces extensions correspondent en fait à une architecture de processeur spécifique.
Le reste de la ligne est composé de plusieurs cd suivi d’un “double pipe” qui est l’opérateur OR pour linux (si le cd /tmp ne fonctionne pas, on essaie cd /var/run etc…)
On ne sait pas grand chose de la menace, mais on sait déjà qu’elle vise un grand nombre de systèmes : en effet l’architecture x86 est présente sur des système classique, alors que les architectures sh4 ou MIPS sont présentes sur des vieux systèmes et des consoles de jeux (PS2, Dreamcast), les processeurs ARM, quant à eux sont surtout présents sur des sytèmes réduits ou embarqués (téléphones, raspberry Pi, caméra de surveillance).
Un virus qui vise des appareils IoT et embarqués, du bruteforce SSH en masse, cela fait penser au botnet mirai.
Après une rapide analyse sur VirusTotal notre suspicion est bien confirmée !
On creuse !
Après ce petit avant gout, j’ai décidé de mettre en place un honeypot plus solide et polyvalent ! Je me suis donc tourné vers T-Pot : un honey pot tout en un mais qui présente plusieurs inconvénients :
-Il est TRÈS gourmand en resources, j’ai donc du trouver un VPS adapté (entre 8go et 16go de ram et une puissance de calcul correcte) pour un prix raisonnable
-La mise en place n’est pas ce qu’on pourrait qualifier de “triviale”, et pour l’installer il faut construire une ISO depuis la source — et, surprise, mais déployer une image qui n’est pas prévue pour être mise sur une machine virtuelle à distance n’est pas une chose forcément facile 🙃.
J’ai donc du trouver un hébergeur qui propose des vps correct à des prix abordables / déployer des ISO personnalisés et éventuellemnt un accès VNC pour permettre la phase d’installation pre-boot, celle-ci ne se faisant pas automatiquement.
Après avoir trouvé mon bonheur chez un hébergeur basé en Allemagne et déployé mon serveur je l’ai laissé tourner pendant environ 3 mois.
L’interface est très concise et permet une vue globale des données collectées (et même une carte des attaques en temps réel sur notre serveur).
Voici les résultats du 3/12/22 au 3/01/23 :
On voit ici que T-pot combine en fait un grands nombre de honeypot pour couvrir le plus de services possibles (Web, SSH mais il émule aussi un serveur windows, ADB etc) et fait un récap des données en utilisant elastic-search et kibana.
Tout les honeypots gardent leur fonctions d’origine, et via le SSH, il nous est possible de récupérer tout les fichiers téléchargés sur le serveurs :
Dans ces archives nous pouvons ainsi collecter tous les malwares et autres fichiers déposés par les attaquants sur notre serveur.
Il y a beaucoup beaucoup d’autres fonctionnalités présentent et qu’il est possible d’exploiter, mais nous resterons sur les malwares pour ce post !
Toujours plus !
Comme dit plus haut, TPOT possède plusieurs honeypot, dont un nommé “dionaea” qui émule une machine windows ouverte, il collecte également les fichiers déposés.
Ce dernier mois j’ai pu constater une recrudescence de fichiers déposés étant tous très similaire, je vais donc tenter de faire une analyse rapide de ceux-ci.
J’ai donc récupéré le fichier “95ae8e32eb8635e7eabe14ffbfaa777b” que j’ai pu observer en environ 95 versions différentes sur le mois de décembre uniquement.
Une première analyse VirusTotal nous indique qu’il s’agit de WannaCry, seulement, lors de l’analyse statique via Ghidra et d’une analyse dynamique, on constate que le malware n’a, à priori, pas beaucoup en commun avec WannaCry original : Aucune trace de demande de ranson et les fichiers ne sont pas touchés et un fichier .exe est droppé :
Cette fonction “PlayGame” n’est normalement pas présente dans les binaires originaux et concrètement, elle dépose le fichier “mssecsvr.exe” (essayant de faire passer ce fichier pour un fichier légitime au yeux des utilisateur en reprenant la nomenclature Windows).
Les fonctions FUN_1000 1016 et 10ab sont en charge de mettre en place le fichier pour qu’il soit crée dans le répertoire C:\WINDOWS\
On peut ainsi supposer que le virus ici est une sorte de “surcouche” à WannaCry, tentant de tromper les détections en ajoutant des étapes supplémentaires.
Plutôt que de s’embéter à confimer nos suppositions en cherchant des traces de WannaCry dans le code décompilé, il est possible de procéder à une analyse dynamique du fichier, pour lui faire déposer le fichier final, puis analyser celui-ci.
J’ai donc utilisé tria.ge pour des questions de rapidité (plutôt que de créer et installer une vm Windows, de désactiver defender, et de fouiller l’image disque pour retrouver le fichier 🙂)
On a donc notre fichier :
En commençant l’analyse, on s’apperçoit rapidement que ça correspond bien à WannaCry avec son ‘killswitch’ :
Je ne vais pas faire une rétro-analyse complète ici, ce n’est pas le but, cependant, il est nécessaire de comprendre que le retro-engineering de malware est crucial pour la sécurité des systèmes : elle permet d’identifier le “comment ?” en arrivant en retrouver par exemple les API et librairies windows utilisées par les attaquants pour effectuer la reconnaissance/la prolifération et éventuellement l’utilisation d’exploit dans certains cas.
Elle peut également permettre de déterminer le “qui ?” en regardant et traçant les addresses de crypto-monnaies dans le cadre de rançons, ou en fonctions des pratiques de certains APT.
Par exemple, ici j’ai trouvé 3 addresses bitcoin dans le code source :
12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94
Qui sont sûrement utilisées pour le paiement des rançons, elles ont reçu en tout presque 55 btc, soit 1 million d’euros (au cours actuel du bitcoin en janvier 2023).
Quelques fonctions :
Concernant le fonctionnement du virus, on peut voir que le fichier utilise la fonction de l’API windows CryptAcquireContextA() en utilisant le provider par défaut de microsoft :
D’après la documentation, on comprends ici que le virus essaie d’établir un handle à un container, qui contient des clées utilisées pour le chiffrement des fichiers. Il utilise ensuite CryptGenRandom() pour créer des clées de chiffrement.
Cependant, malgré mes efforts, je n’ai trouvé aucune utilisation de la fonction CryptReleaseContext qui est censée ‘effacer’ les clées de la mémoire, ce qui signifie que les clées de chiffrement sont potentiellement gardées en mémoire, et permettrait en théorie, de récupérer ces clées afin de procéder à un déchiffrement des fichiers endommagés.
Le mot de la fin
Il est important de noter que je n’ai fait qu’éfleurer le monde de l’analyse de malware et du Threat Intelligence. L’analyse statistiques des données et des échantillons de malwares sont également des bonnes pistes pour l’analyse de menace, et elles feront sûrement l’objet d’un prochain post !