# **Test de pénétration de domaine : active directory** Je travaille aujourd'hui en alternance en tant que consultant modern workplace Microsoft dans une ESN de la place, l'ensemble des projets effectué chez nos client en mode Legacy ou modern repose essentiellement sur l'identité (Active directory), bien que très souvent ces identités soient migrés vers Azure AD, via le billet de l'AD Connect, on se rend compte que le "coeur" du système d'information reste bel et bien la base de donnée ntds. dit de l'active Directory.Un attaquant qui reussit à entrer en possesion des "bons identifiants" peut donc accéder au controlleur de domaine et mettre à mal le système d'information. Raison pour laquelle j'ai décidé d'effectuer des tests d'intrusion dans mon AD local (**Attention l'ensemble des tests effectués sont réalisés en virtualisation !!!**) > []Ce lab est inspiré de celui réalisé par Hemza KONDA formateur chez Alphorm > Présentation du LAB ![](https://i.imgur.com/gnBC3tV.png) au sein de notre domaine nommé alphorm.lab, nous avons deux postes utilisateurs sous windows 10 avec les identifiants suivant : * l'utilisateur 1 , * l'utilisateur 2, * Le controleur de domaine, * Un attaquant sur kali linux hors domaine, ayant accès au réseau local > Kill Chain Active Directory ![](https://i.imgur.com/O4EBwdH.png) ![](https://i.imgur.com/8NbsoGw.png) Entrons à présent dans le vif du sujet, 1. Attaque d'usurpation LLMNR / NBT-NS * capturer les informations d'identification du réseau à l'aide de Kali + Responder.py qu'on fasse parti de l'equipe infra ou qu'on soit un simple utilisateur, nous avons déja tous effectué une erreure lors la saisie du chemin réseau d'un partage de fichier (ex : \\share) ou alors nous saissisons le bon chemin réseau mais les droits d'accès au fichier viennent de nous être attribué mais le système ne l'a pas encore pris en compte ceci dû à un léger temps de latence. Dans les deux cas, la requête au prêt du serveur de noms DNS échoue et les systèmes Microsoft Windows utilisent la résolution de noms Link-Local Multicast (LLMNR en abrégé) et le service de noms Net-BIOS (NBT-NS) pour la résolution de noms de secours. si le réseau n'est pas cible d'une attaque LLMNR / NBT-NS l'utilisateur reçoit le pop-up d'erreur suivant : ![](https://i.imgur.com/l8uGEmB.png) Par contre si le réseau est cible de cette attaque, l'utilisateur recevra une fenêtre d'authentification (inconsciement il va entrer ses identifiants) à cet instant l'attaquant utilise un outil comme Responder.py ou Metasploit pour transmettre les requêtes à un service malveillant (comme SMB TCP : 137) qui effectue le processus d'authentification. Pendant le processus d'authentification, le client enverra au serveur non autorisé un hachage NTLMv2 pour l'utilisateur qui essaie de s'authentifier, ce hachage est capturé sur le disque et peut être craqué hors ligne avec un outil comme Hashcat ou John the Ripper (TJR) ou utilisé dans une passe -l'attaque de hachage. > diagramme d'une attaque typique du serveur de noms LLMNR / NetBIOS ![](https://i.imgur.com/sc9TvLe.png) * L'utilisateur envoie une adresse de partage SMB incorrecte\\ * Le serveur DNS répond avec\\SNARE01 - NOT FOUND * Le client effectue une diffusion LLMNR / NBT-NS * Le répondeur indique au client qu'il s'agit de SNARE01 et accepte le hachage NTLMv2 * Le répondeur renvoie une erreur au client, de sorte que l'utilisateur final n'est pas plus sage et pense simplement qu'il a le mauvais nom de partage * > **CAS PRATIQUE Utilisation de Kali & Responder.py** Nous commençons par démarrer whireshark pour sniffer le réseau, puis dans un terminal nous executons la ligne de commande suivante permettant de créer un faux serveur: ![](https://i.imgur.com/WeqNS0g.png) explication des options : -r:activer les reponses pour les requetes de suffixe netbios, -d: repondre aux requettes de suffixe de domaine netbios, -w: repondre au requette WPAD, -v: Verbose. dès lors mon serveur reste à l'affut des potentiels requêtes de suffixe Netbios ou WPAD, ![](https://i.imgur.com/nZGEmw2.png) rendons nous sur le poste de l'utilisateur 1, essayons d'acceder à un partage de fichier innexistant (\\unamed007). Le chemin réseau étant innexistant, le serveur simmulé par Responder renvoit immédiatement un fenêtre demandant à l'utilisateur de renseigner ses identifiants. l'utilisateur saisie ses identifiants ![](https://i.imgur.com/rOawDZ5.png) et à cet instant le faux serveur SMB de l'attaquant va capturer le Hash NTLM de l'utilisateur comme presenter dans la figure ci-dessous ![](https://i.imgur.com/NQAJGx4.png) on voit donc bien le username (Kaile.aura) et le Hash du mot de passe (ALPHORMLAB:216e9690...0000) à présent nous allons dans le repertoire `/usr/share/responder` repertoire dans lequel se trouve tous les hash capturer par le serveur SMB ![](https://i.imgur.com/k5RX1PT.png) nous allons copier le hash, créer un nouveau fichier nommé hash.txt à l'aide de la commande touch hash.txt puis à l'aide de l'editeur vim nous allons coller le hash copier précedement dans ce fichier. Dès lors grace à l'outil hashcat nous allons casser se mot de passe. pour ce faire kali linux nous propose une plétore d'outil (metasploit,hashcat,rockyou...) que nous retrouvons dans le repertoire `/usr/share/wordlists/` dans ce TP nous allons utiliser l'outil Hashcat! il suffit de saisir la commande suivante : `sudo hashcat -m 5600 hash.txt /usr/share/wordlists/fasttrack.txt --force` ![](https://i.imgur.com/FB2JTFo.png) Une fois le hash craqué nous voyons le statut cracked et le mot de passe spécifié, ![](https://i.imgur.com/7BZmenc.png) **KO!** > Comment se protéger de l'attaque LLMNR / NBT-NS Pour se protéger de cet attaque il faut désactiver le service de noms NetBios et le LLMNR * Désactiver le service de noms NetBIOS Il semble qu'il n'y ait aucun moyen de désactiver le service de noms NetBIOS à l'aide d'un GPO les instructions manuelles sont ci-dessous. 1. Ouvrir : Panneau de configuration\Réseau et Internet\Connexions réseau 1. Faites un clic droit sur l'interface réseau, sélectionnez les propriétés, double-cliquez sur « Internet Protocol Version 4 TCP/IPv4 » 1. Sur l'écran suivant, cliquez sur avancé, puis sélectionnez l'onglet WINS 1. Cliquez sur le bouton radio à côté de « Désactiver NetBIOS sur TCP/IP » ![](https://i.imgur.com/9DrUwVA.png) * Désactiver LLMNR Nous pouvons désactiver LLMNR à l'aide d'un GPO, instructions ci-dessous : 1. Démarrer => Exécuter => gpedit.msc, Ouvrez « Local Computer Policy » => « Computer Configuration » => « Administrative Templates » => « Network » => « DNS Client » 1. Cliquez sur "Désactiver la résolution du nom de multidiffusion" et réglez-le sur "Activé ![](https://i.imgur.com/jLdip8P.png) ![](https://i.imgur.com/YaJO8Yk.png) .