Ce rapport constitue le premier scénario d’attaque défense du laboratoire. L’objectif est d’évaluer la sécurité de la configuration du Firewall, de mettre en pratique les règles précédemment créées concernant l’authentification sur Windows Server et Windows Metasploit. De plus, divers outils seront testés afin de mettre en pratique l’OpSec, c’est-à-dire le fait de cacher sa trace, ou encore de trouver des vulnérabilités à exploiter.
Bien que le laboratoire ait été achevé, l’utilisation de Nessus nécessite la création d’une nouvelle machine. Il s’agira d’une machine Linux en mode CMD, exactement comme Velociraptor, avec les configurations suivantes :
Une fois le système d’exploitation terminée, je passe à l’installation de Nessus dans la machine.
Une fois que le service est démarrer, je passe à la configuration des cartes réseaux de la machine, pour qu’elle puisse scanner Windows Server et Windows Metasploit.
Afin d’accéder à l’interface Web de Nessus, j’utilise l’URL suivante : https://192.168.3.89:8834
La première étape de l’attaque consiste à repérer les différents équipement du réseau. Cette phase va permettre de faire du repérage dans le réseau et de localiser le Firewall, qui constitue la première cible.
L’objectif de ce scan est de trouver tous les hôtes avec le port 80 ou 443 ouvert. Il s’agit des ports HTTP et HTTPS. Un Firewall ou autre machine de management ou de surveillance doit forcément être accessible via interface Web. Après avoir analyser les résultats du scan, les machines ayant les ports HTTP et/ou HTTPS ouverts sont les suivantes :
Après avoir accéder à chacune de ces adresses IP sur mon navigateur, j’ai trouvé que l’adresse IP 192.168.3.76 est celle du Firewall. L’étape suivante est donc le scan d’OS et de version afin de voir si certaines informations peuvent être révélées :
Après analyse du résultat je remarque les informations suivantes :
Il s’agit de la configuration du Firewall. Je peux voir son nom, à savoir FortiGate, qu’il appartient à l’organisme Fortinet et également le pays dont l’appareil est origine : Californie aux USA. La donnée la plus importante reste la configuration réseau. En effet je constate qu’il y a 3 adresses IP : 192.168.3.76, 23.56.89.1, 12.45.78.1. Je peux donc conclure que la première est l’adresse IP dans le réseau local, étant donné que c’est cette adresse que j’ai scanné, et que Fortinet possède deux sous réseaux 23.56.89.1 et 12.45.78.1.
La prochaine étape de l’attaque est l’infiltration d’EvilCard dans les deux sous réseau de Fortinet. Cette phase est essentielle, puisqu’elle va permettre de communiquer avec les machines des sous réseaux. Étant donné que les MSR ne sont pas spécifier, je vais utiliser un /24 afin de voir si certaines machine sont présentes dans ce premier segment.
Une fois que la machine est dans les deux sous réseaux, je refais un scan avec Nmap afin de repérer les différentes machines qu’ils contiennent. Je commence d’abord avec le sous réseau de la carte wlan1, concernant le type de scan, il s’agira d’un scan d’OS.
Après analyse des résultats, je remarque que dans le sous réseau 4 machines sont détectées, et parmi elles une machine Windows avec un OS obsolète :
Après analyse, Nmap n’a retourné aucune vulnérabilité, je me suis donc tourné vers une solution plus puissante et adapté, à savoir Nessus :
Après analyse, Nessus n’a notifié aucune vulnérabilité critique, l’exploitation est donc impossible depuis le Firewall :
Voici donc le rapport généré depuis Nessus
Cela s’explique par le fait que la machine appartient à un domaine Windows. Je vais donc vérifier s’il existe une faille d’architecture qui me permettrait de réaliser un scan de vulnérabilité. Pour cela je vais faire un scan de version sur l’ensemble de mon laboratoire pour vérifier si une machine a une configuration similaire à Fortinet, c’est-à-dire avec plusieurs interfaces, ou alors s’il existe un autre machine avec une version de Windows obsolète :
Après avoir analyser le résultat de ce scan réseau, je remarque qu’il existe une machine dont l’OS est Microsoft Windows 7, et son adresse IP est 192.168.3.96 :
Suite à ce résultat j’ai réalisé un scan de vulnérabilités avec Nessus, et j’ai obtenu les résultats suivants :
Le compte rendu de Nessus est que la machine est vulnérable à la faille MS17-010.
Maintenant qu’une faille a été découverte je vais l’exploiter pour m’introduire dans la machine. Le premier objectif de la pénétration est de récupérer l’ensemble des mots de passe de la machine pour pouvoir me connecter à celle-ci à l’aide de ses identifiants. Le deuxième objectif est l’analyse de la machine et l’identification des services qu’elles contient ou auxquelles elle est connectée. Pour ce faire, je vais utiliser Metasploit.
Maintenant que j’ai pénétré la machine, j’ai migré vers un processus plus discret et affiché les informations du système :
Je remarque que la machine pénétrée appartient à un domaine qui s’appelle LAB, ce qui implique qu’un contrôleur de domaine se trouve dans le réseau. Pour trouver l’adresse IP du contrôleur de domaine je vais lancer un reverse shell et voir la configuration réseau de la machine précédemment corrompue :
La machine a deux interfaces réseaux : la première correspond à celle dans le réseau du laboratoire et l’autre à celle dans le sous réseau Fortinet. Cela prouve donc que je suis bien dans la machine que je voulais attaquer au départ. Dans la deuxième carte réseau l’adresse IP du serveur DNS est 12.45.78.254. En se basant sur la configuration nécessaire pour ajouter une machine dans un domaine, je peux en conclure que cette adresse est bien celle du contrôleur de domaine. Il ne reste plus qu’à savoir de quelle système d’exploitation il s’agit pour pouvoir ensuite l’attaquer. Pour terminer avec l’attaque sur Windows Metasploit, je vais récupérer tous les mots de passe de la machine :
Maintenant que les hash ont été récupérés, je vais les attaquer afin de trouver le mot de passe de l’utilisateur Administrateur qui correspond à l’utilisateur du domaine LAB.
Les hash windows se composent des parties suivantes :
NomUtilisateur:RID:LM_hash:NT_hash:::
NomUtilisateur → nom du compte
RID → Relative Identifier
LM_hash → hash LM
NT_hash : hash NT
L’attaque est cependant inutile car les hash des comptes Invité et Administrateur sont les même. Cependant, le compte Administrateur a un mot de passe contrairement au compte invité. J’ai tout de même
mené l’attaque sur le hash des utilisateurs User et Administrateur, afin de confirmer mon hypothèse :
Il est possible depuis le CMD Windows de modifier le mot de passe d’un utilisateur avec la commande « net user », à condition d’être un utilisateur privilégié. J’ai donc choisi cette option afin de pouvoir ensuite me connecter au contrôleur de domaine.
Étant donné que je n’ai pas réussi à utiliser Windows Metasploit pour m’attaquer au contrôleur de domaine, j’ai décidé de mener une attaque physique sur la machine. Pour ce faire je vais utiliser une clé Rubber Ducky qui permettra de cacher et d’exécuter un trojan dans la machine. Mais avant ça, il me faut d’abord identifier le système d’exploitation de la machine afin d’y adapter le programme Python de la clé. J’avais précédemment trouvé l’adresse IP du DC depuis la configuration réseau de Windows Metasploit, à savoir 12.45.78.254. Je vais donc, dans un premier temps effectuer le scan d’OS de l’IP 12.45.78.254 :
Nmap me révèle plusieurs informations, notamment le nom de l’hôte (WINDOWS-SERVER), l’OS de la machine (Windows Server 2019). Ainsi, je vais pouvoir créer mon cheval de troie, à l’aide de MsfVenom, et créer le programme Python adapté à Windows pour ma clé HackiPy.
La première étape est la préparation de la clé, qui se fait en deux étapes. La première est l’implémentation du programme de celle-ci, permettant le téléchargement du trojan depuis WebVirus. La deuxième est la création du trojan à l’aide de msfvenom, et son hébergement dans WebVirus. Grâce à l’IA, j’ai généré un programme permettant de télécharger le trojan depuis WebVirus, et le lancer dans la machine cible de manière discrète.
Une fois que l’ensemble des étapes de préparation ont été faites, je passe à l’attaque. Je commence tout d’abord par copier la base NTDS.dit et le fichier SYSTEM à l’aide de MiniWindows :
Ces fichiers vont permettre de trouver le hash du mot de passe du contrôleur de domaine. Pour ce faire, j’utilise l’outil impacket-secretsdump :
La prochaine étape est le cracking du hash Administrateur, puisque dans ce cas là il ne s’agit pas de l’utilisateur local mais celui du contrôleur de domaine. De plus, il ne s’agit pas d’un hash vide :
Le mot de passe Administrateur de l’AD est donc « P@ssword ». A partir de là, je peux me connecter au serveur et brancher ma clé HackiPy pour pénétrer la machine, et activé le protocole RDP (port 3389).
L’objectif de l’attaque, ayant pour objectif la prise de contrôle de l’AD a été accompli.
La première machine à analyser est Windows Metasploit. Il s’agit de la première machine depuis laquelle Qradar a signalé des alertes. Toutes les alertes provenaient de l’utilisateur « ANOYMOUS LOGON », ce qui signifie que des connexions anonymes ont eu lieu. Pour les retrouver, je vais effectuer une recherche rapide sur l’outil :
Voici le résultat obtenu après avoir effectué cette recherche :
On remarque trois niveau de magnitude, qui correspond au niveau de gravité :
Les logs qui vont donc m’intéresser sont ceux de magnitude 4 et 6. Le fait qu’ils proviennent de machines externes et que les ports utilisés ne sont pas commun suggère qu’une cyberattaque a été menée contre cette machine Windows. Ainsi, en m’appuyant sur les éléments suivants :
Je conclus que des scans et des pénétrations ont été commis contre Windows Metasploit. La machine a donc été exploitée, mais je ne dispose d’aucun moyen de traçabilité qui me permettrait de savoir ce que l’attaquant a commis dans la machine. Cependant, elle est client AD DS, l’attaquant s’est donc sûrement servi de celle-ci pour pénétrer le contrôleur de domaine, à savoir Windows Server.
Concernant les logs de Windows Server, mise à part les connexion légitime à la machine aucun autre log n’est notifié :
Cependant, je remarque que certaines connexions sont illégitimes, étant donné que j’en ai pas été l’auteur. Cela me laisse penser que l’attaquant a réussi à pénétrer le serveur. Je vais donc examiner l’état de la machine afin de voir si une modification est constatable.
Après avoir examiné les différents ports de la machine, j’ai remarqué que le port 3389, c’est à dire le port associé au protocole RDP, qui signifie Remote Desktop Protocol, est en écoute. Hors, d’origine ce n’était pas le cas. J’en conclu donc qu’une attaque à bien eu lieu contre le DC. Il ne me reste plus qu’à déterminer comment est ce que cette attaque à eu lieu. Le fait qu’aucun log suspect a été reporté par le SIEM supprime l’hypothèse d’une intrusion par exploitation de vulnérabilité. La prochaine étape est donc l’analyse du trafic réseau au moment de chaque connexions suspectes. Après avoir analysé le trafic réseau en considérant comme source Windows Server, avec Wireshark, j’ai constaté de nombreuse requêtes allant vers une adresse IP inconnue. Le paquet suivant est une requête HTTP vers l’adresse IP 192.168.3.105 :
Je remarque qu’un fichier a été téléchargé depuis le serveur web 192.168.3.105. J’ai donc exporté les objets HTTP afin d’analyser le fichier « WinUpdate.exe » avec VirusTotal.
Après analyse, le fichier est malveillant et fait partie des catégories « Trojan » et « Hacktool ». C’est donc un cheval de troie.
Le premier point d’entrée a été Windows Metasploit. En pénétrant la machine, le hacker a pu prendre connaissance de la configuration de la machine et découvrir qu’elle appartient à un domaine Windows. Il a ensuite mené une attaque physique sur le serveur Windows, étant donné qu’aucune autre connexion suspecte a été notifiée sur le SIEM. L’objectif de cette attaque a été la possibilité de contrôler Windows Server via le protocole RDP, et pour y arriver le pirate a installé et lancé un cheval de troie dans le serveur. L’état de la machine laisse penser a une installation caché puisqu’aucun exécutable a été trouvé dans celle-ci. Ainsi, plusieurs correctifs sont à apporter sur les points suivants :
Avant de commencer le renforcement de la sécurité des machines victimes, je dois d’abord établir un ordre de priorité des différents correctifs à apporter. La priorité la plus haute est Windows Server, ce qui implique le renforcement de l’accès physique de la machine, la fortification du mot de passe du domaine et la sécurisation du Bios. Pour une sécurité optimale, j’ai totalement désactivé la lecture de périphériques USB par le serveur. La deuxième priorité haut est Windows Metasploit. Cette machine tourne sous Windows 7, une version Windows aujourd’hui obsolète. De plus de nombreuses versions Windows Microsoft antérieures à Windows 10 ont la faille EternalBlue. Ainsi, celle-ci doit être patché afin de garantir la sécurité de l’architecture AD DS. La troisième priorité est la configuration du Firewall. La faille présente sur cette machine est une mauvaise configuration. Le fait que les subnets réseaux soient visibles après un scan réseau constitue une faille dans l’architecture AD DS, même si les machines qui constituent cette configuration ont été sécurisées. Enfin, il est également possible de revoir la configuration de l’architecture AD DS en garantissant un accès Internet sans avoir à utiliser deux cartes réseaux pour chaque machine. Voici un tableau récapitulatif des différentes machine à corriger en fonction des points précédemment abordés :
La première étape va être la sécurisation du Bios de Windows Server. J’ai donc modifié les paramètres de la machine pour qu’elle démarre sur le Bios et non sur le EFI, puis j’ai ajouté un mot de passe afin que seul l’administrateur système puisse accéder au Bios de celle-ci. Cela permet donc d’éviter qu’un utilisateur malveillant où autre personne malveillante puisse démarrer la machine sur un autre OS.
La prochaine étape de la sécurisation du serveur Windows est le blocage des ports USB de la machine. Pour ce faire, je vais passer par les GPO. Avant de réaliser cette étape, j’ai dû réinstaller Windows Server, étant donné que le microprogramme de démarrage de la machine a été modifié. Une fois l’installation terminée et le domaine recréé, j’ai supprimé la possibilité a tout utilisateur de pouvoir lire et écrire sur des support de disque amovible. Pour ce faire j’ai modifié la valeur « Start » de USBSTOR :
Pour finir avec les correctifs concernant Windows Server, je vais modifier le mot de passe du domaine, afin d’augmenter sa complexité de déchiffrement. Aujourd’hui, un bon mot de passe doit suivre les règles suivantes :
Une fois la machine Windows Server sécurisée, je suis passé à la deuxième priorité de l’architecture AD DS, à savoir Windows Metasploit. Concernant cette machine, seul la faille EternalBlue est à corriger. Pour ce faire, je dois d’abord comprendre le comportement de la faille MS17-010, et comment EternalBlue (nom de l’exploit) tire partie de cette faille. EternalBlue, nom du mécanisme d’exploitation, exploite la vulnérabilité MS17-010 présente dans la version 1 du protocole SMB. L’objectif est de pouvoir exécuter un payload, qui est le programme exécuté par l’exploit, afin de pouvoir prendre le contrôle total de la cible. Donc, pour sécuriser ma machine, il me suffit d’installer la mise à jour de sécurité Windows « Windows6.1-kb4012212-x64.msu ».
Lien de téléchargement : patch_faille_ms17-010
Une fois la machine redémarrée et le patch installé, j’ai effectué un nouveau scan avec Nessus, et cette fois-ci, la faille n’a pas été reportée comme on peut le constaté dans le rapport suivant.
La dernière machine à corriger est le pare-feu Fortinet. En effet, lors de la configuration de celle-ci je n’ai appliqué aucune sécurité quant à la visibilité des sous réseaux de celui-ci. Ainsi, il est fort probable que le pirate ait découvert les sous réseaux en scannant Fortinet. Ainsi, il est donc indispensable de palier ce risque et de configurer le pare-feu comme il se doit. Afin de rendre les interfaces discrètes, j’ai tout simplement supprimé tous les accès administratif sur les deux interfaces des sous réseaux LAN-CLIENT et LAN-SERVER. Après avoir demandé un scan de Fortinet, voici les résultats transmis :
Lors de l’analyse des logs, je me suis rendu compte que certaines informations manquaient, ce qui a ralentit l’enquête. Ainsi, j’ai décidé de palier à ce soucis en créant des alertes concernant les différents équipements, mais également de surveillé l’ensemble de l’infrastructure AD DS en incluant le pare-feu.
La dernière étape à réaliser pour avoir une visibilité totale sur l’infrastructure AD DS, et pour pouvoir agir dans les temps en cas d’attaque est la création de règles et de rapports. Voici les différentes règles à créer sur Qradar :
Résultats :
Résultats :
Résultats :
Grâce à ces nouveaux rapports et règles, la traçabilité concernant l’infrastructure AD DS est nettement améliorée. Il m’est donc maintenant possible de pouvoir être avertit directement en cas d’activités suspectes, et d’avoir un suivi de celle-ci.
L’objectif de ce scénario a été de mettre en lumière différents aspects de la sécurité informatique, c’est-à-dire l’importance de la solidité des mots de passe, la sécurisation de l’accès physique et la maintenance des systèmes informatique. Bien que cela paraisse logique, il est également important de pouvoir garantir une traçabilité et une surveillance approfondit et constante de toute son infrastructure.