Comment et pourquoi désactiver LLMNR et NetBIOS ? (2024)

I. Présentation

Dans ce tutoriel, nous allons partir à la découverte du protocole LLMNR, ainsi que du protocole NetBIOS ! Utilisé en environnement Windows pour effectuer de la résolution de noms, LLMNR est un protocole vulnérable à différentes attaques qu'il est préférable de ne pas utiliser et de désactiver.

Après une présentation du protocole LLMNR et de son fonctionnement, nous verrons quels sont les risques liés à son utilisation avant de voir comment le désactiver dans un environnement Active Directory. Nous verrons également comment désactiver le protocole NetBIOS.

• Voir la vidéo sur YouTube

II. Qu'est-ce que le protocole LLMNR ?

Le protocole LLMNR pour Local Link Multicast Name Resolution, est un protocole utilisé en environnement Windows pour effectuer de la résolution de noms localement, c'est-à-dire via l'émission d'un paquet sur le réseau local. LLMNR est le successeur de NBT-NS (NetBIOS) et il a été introduit dans Windows Vista pour la première fois.

Vous allez me dire : "LLMNR n'est pas utile puisque l'on utilise le DNS ?". C'est vrai, mais aujourd'hui LLMNR est toujours activé par défaut sur Windows donc il est susceptible d'être utilisé. Sachez que cela se produira dans le cas où la résolution DNS échoue. Ce qui est bien plus fréquent qu'on ne le croit sur un système d'information, une simple typo dans le nom d'un serveur suffit à générer l'émission de plusieurs requêtes LLMNR sur le réseau. Aussi, les noms requêtés peuvent provenir d'erreur dans la configuration, d'ancien nom de domaine qui ne sont plus utilisés, d'un poste qui change de réseau fréquemment, etc.

Sachez également que dans un environnement en "workgroup", le protocole LLMNR est utilisé pour effectuer la découverte du réseau.

Lorsque nous tentons de résoudre un nom à partir d'une machine Windows, le système d'exploitation va effectuer la vérification dans cet ordre (comme indiqué dans la documentation Microsoft) :

1 - Le nom d'hôte demandé est-il celui de la machine locale ?

2 - Le nom d'hôte demandé est-il indiqué dans le fichier hosts de la machine (C:\Windows\System32\drivers\etc\hosts)

3 - Le nom d'hôte demandé est-il présent dans le cache DNS de la machine ? Ceci revient à consulter le cache local avec la commande PowerShell "Get-DnsClientCache" ou la commande "ipconfig /displaydns".

4 - Le nom d'hôte demandé reste introuvable, donc Windows va solliciter le serveur DNS configuré sur l'interface réseau active de la machine.

5 - En dernier recours, si aucune réponse n'est obtenue, Windows va émettre deux requêtes sur le réseau : une requête NBT-NS en broadcast et une requête LLMNR en multicast afin de tenter d'obtenir une réponse. Nous pouvons dire que LLMNR repose sur le principe du voisinage réseau.

6 - Aucune réponse : échec de la recherche

Vous l'aurez compris : la recherche s'arrête à partir du moment où le nom a pu être résolu par Windows. Ainsi, si le nom d'hôte demandé est identifié dans le fichier hosts, alors Windows ne sollicitera pas son cache DNS, ni même le serveur DNS configurés sur la carte réseau, et il n'utilisera pas non plus le protocole LLMNR.

Remarque : le protocole LLMNR fonctionne en UDP sur le port 5355.

III. Qu'est-ce que le protocole NetBIOS ?

Au même titre que LLMNR, le protocole NetBIOS over TCP/IP, appelé également NBT-NS, est utilisé pour effectuer de la recherche de ressources sur un réseau local.

Contrairement au LLMNR qui diffuse une requête multicast, le NetBIOS diffuse une requête de broadcast lorsqu'il effectue une recherche. Autre différence : NetBIOS fonctionne uniquement en IPv4, alors que LLMNR fonctionne aussi bien en IPv4 qu'en IPv6.

Remarque : le protocole NetBIOS s'appuie sur plusieurs ports pour fonctionner (ports137/UDP, 138/UDP et 139/TCP).

IV. Quels sont les risques associés à LLMNR et NetBIOS ?

A. Poisoning et MiTM

Le protocole LLMNR (ainsi que le NetBIOS) est vulnérable à des attaques de type poisoning et man-in-the-middle (MiTM).

Si une machine Windows tente de résoudre un nom d'hôte, elle va chercher à obtenir une réponse en sollicitant les services de résolutions de noms dans l'ordre évoqué précédemment dans cet article. Si ce processus arrive jusqu'à la fin, Windows va émettre un paquet LLMNR en multicast sur le réseau pour tenter d'obtenir une réponse... C'est là qu'un attaquant peut intervenir en se faisant passer pour l'hôte recherché par le client Windows.

En effet, si un attaquant répond à une requête LLMNR, il peut envoyer une fausse information à la machine Windows. Celle-ci ne sera pas capable de déterminer si la réponse est légitime ou non, ni même à quoi correspond l'hôte de destination, car il n'y a aucune authentification. Ainsi, la machine Windows sera susceptible de tenter une authentification auprès du serveur contrôlé par l'attaquant.

Grâce à cela, l'attaquant peut récupérer des identifiants, que ce soit le hash Net-NTLM, des identifiants HTTP, etc... En fonction du type de service. S'il s'agit d'un hash Net-NTLM, il sera possible de le réutiliser ou de le casser à l'aide d'un outil tel que hashcat ou John The Ripper.

Si l'authentification Windows utilisée repose sur NTLMv2 (donc un challenge-réponse), les échanges récupérés seront plus difficiles à casser pour récupérer le mot de passe utilisateur. Il reste possible d'effectuer une attaque dite SMB-relay, qui consiste pour l'attaquant à jouer les intermédiaires entre le client empoisonné et le serveur légitime, afin d'usurper la session SMB d'un utilisateur sans connaitre son mot de passe.

B. LLMNR poisoning avec Responder

Si vous souhaitez mettre en pratique ce type d'attaque, vous pouvez utiliser l'outil Python Responder. Il présente l'avantage de prendre en charge différents types de services pour "piéger" la machine Windows (SMB, HTTP, HTTPS, LDAP, etc.), aussi bien en IPv4 qu'en IPv6. Nous pouvons l'utiliser facilement puisqu'il est intégré à Kali Linux.

Imaginons une machine sous Windows Server (ou Windows), à partir de laquelle nous souhaitons accéder à un serveur de fichiers nommé "srv-fichier". Et une seconde machine, sous Kali Linux, avec l'outil Responder. Toutes les machines sont connectées sur le même réseau.

Tout d'abord, nous allons préparer la machine de l'attaquant. L'outil Responder contient de nombreuses options, mais nous allons simplement l'exécuter avec les options par défaut et le mettre en écoute sur l'interface "eth0" de la machine Kali Linux :

sudo responder -I eth0

A partir de ce moment-là, Responder est en attente... Il est à l'écoute du trafic réseau, notamment des requêtes LLMNR et NBT-NS.

Depuis le serveur Windows, nous allons accéder au serveur "srv-fichier" via le protocole SMB donc nous allons utiliser un chemin UNC : "\\<nom du serveur>\". Nous allons volontairement effectuer une erreur de saisie dans le nom (ce qui dans la vie réelle, peut arriver !) :

\\srv-fichiers\

Ainsi, le serveur DNS ne pourra pas nous rediriger vers notre serveur de fichiers, car il ne connait pas "srv-fichiers". Notre machine Windows Server va donc solliciter le réseau local pour "localiser" cet hôte... C'est là que Responder intervient !

En temps normal, nous aurions obtenu une erreur puisque Windows ne parvient pas à localiser notre serveur... Mais là, une fenêtre "Entrer les informations d'identification réseau" s'affiche afin que l'on puisse saisir nos identifiants dans le but de nous authentifier auprès du serveur "srv-fichiers". Tant qu'à faire, nous allons indiquer le compte Administrateur du domaine Active Directory auquel appartient notre serveur...

Sauf que nous ne sommes pas en train de nous authentifier auprès du serveur de fichiers, mais auprès de Responder ! Il a répondu à la requête LLMNR émise par l'hôte la machine Windows Server au moment où l'on cherchait à résoudre le nom "srv-fichiers". Notre client Windows Server a été empoisonné par Responder !

Ainsi, Responder est parvenu à collecter le nom d'utilisateur et le hash NTLMv2 du mot de passe saisi dans la fenêtre "Entrer les informations d'identification réseau". Une information sensible que l'on peut réutiliser via la technique Pass-the-hash ou que l'on pourrait essayer de "craquer" pour obtenir le mot de passe en clair...

Ceci est une démonstration très simple basée sur un accès SMB, mais elle met en évidence les faiblesses des protocoles LLMNR / NetBIOS ! Une erreur de saisie, un peu de naïveté, et on laisse fuiter des identifiants...! Dans un scénario man-in-the-middle, ceci serait possible, y compris avec un nom légitime de serveur.

Pour finir sur cette partie, sachez qu'il est possible d'utiliser Responder en mode "passif" grâce à l'option -A. Alors, il va simplement journaliser les paquets qu'il aurait pu exploiter (LLMNR/NBT-NS) sans tenter d'empoisonnement. C'est notamment utile si vous souhaitez avoir un diagnostic rapide concernant l'utilisation de ces protocoles sur votre réseau, sans tenter d'attaque. À noter qu'une analyse Wireshark avec un filtre LLMNR fera également l'affaire pour un diagnostic.

V. Active Directory : comment désactiver le protocole LLMNR ?

Dans un environnement Active Directory, les protocoles LLMNR et NetBIOS ne sont pas nécessaires pour assurer un fonctionnement normal. Ainsi, nous allons pouvoir les désactiver !

Toutefois, ne déployez pas massivement ce changement : effectuez des tests et déployez progressivement cette modification. Pourquoi ? Et bien, certains périphériques, notamment des imprimantes, peuvent avoir besoin du LLMNR (ou du NetBIOS) pour fonctionner.

Pour désactiver l'utilisation du LLMNR, vous devez créer une nouvelle stratégie de groupe afin de configurer un paramètre.

• Comment créer une stratégie de groupe ?

Ce fameux paramètre se situe à l'emplacement suivant :

• Configuration ordinateur > Modèles d'administration > Réseau > Client DNS

A cet endroit, vous pourrez localiser un paramètre nommé "Désactiver la résolution de noms multidiffusion" (ou "Turn off multicast name resolution" en anglais).

Vous devez configurer le paramètre sur "Activé" pour désactiver la résolution de noms basée sur LLMNR.

La GPO est prête ! Un seul et unique paramètre de GPO est suffisant pour désactiver LLMNR sur les machines Windows. Il suffit de lier la GPO de manière à l'appliquer aux machines de votre environnement Active Directory.

VI. Active Directory : comment désactiver le protocole NetBIOS ?

Pour désactiver le protocole NetBIOS, nous pouvons procéder de différentes façons : voici trois méthodes que vous pouvez utiliser.

A. Désactiver manuellement le NetBIOS

Sous Windows, l'activation/désactivation du NetBIOS s'effectue interface réseau par interface réseau. Autrement dit, NetBIOS peut être activé sur une interface réseau et désactivé sur autre interface réseau.

Pour désactiver manuellement le NetBIOS sur une interface réseau, ouvrez le "Panneau de configuration", cliquez sur "Centre Réseau et partage" puis sur le nom de la carte (par exemple "Ethernet0") afin de cliquer sur "Propriétés". Ensuite, sélectionnez "Protocole Internet version 4 (TCP/IPv4)" et cliquez sur "Propriétés".

Vous allez obtenir la fenêtre présentée ci-dessous. Il vous suffira de :

1 - Cliquer sur le bouton "Avancé..."

2 - Cliquer sur l'onglet "WINS"

3 - Cocher l'option "Désactiver NetBIOS sur TCP/IP" au lieu de "Par défaut"

Validez, le tour est joué ! Cette action doit être répétée sur chaque interface réseau (et sur chaque machine) !

B. Désactiver le NetBIOS par GPO

Pour désactiver le NetBIOS explicitement sur chaque interface réseau de Windows, nous allons devoir configurer le Registre Windows. Si l'on regarde de plus près le Registre Windows, nous pouvons voir que sous :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\

Il y a une clé de Registre par interface réseau présente sur la machine. À chaque fois, chaque clé de Registre contient une valeur nommée "NetbiosOptions" qui indique si le NetBIOS est activé ou désactivé. En fait, c'est le reflet de l'option que nous avons configurée précédemment (méthode manuelle).

Nous remarquons également que chaque clé est nommée sous la forme "Tcpip_{ID}" et ces valeurs seront différentes d'une machine à une autre. Mais, finalement, ce n'est pas un problème, car une seule et unique commande PowerShell va nous permettre de désactiver NetBIOS sur toutes les interfaces de la machine en configurant l'option "NetbiosOptions" dans le Registre :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\tcpip_*' -Name NetbiosOptions -Value 2 -Verbose

Le fait d'ajouter le paramètre "-Verbose" permet d'en savoir plus sur les actions effectuées par la commande. Ceci est utile pour vérifier que PowerShell modifie bien l'option de chaque interface réseau présente dans le Registre (sous "Interfaces").

COMMENTAIRES: Opération «Définir la propriété» en cours sur la cible «Élément: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{04d8a5a6-b0cc-47ac-9db9-66e7d949eee3} Propriété: NetbiosOptions».COMMENTAIRES: Opération «Définir la propriété» en cours sur la cible «Élément: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{56acc37a-293b-4036-8ed6-074387cd226d} Propriété: NetbiosOptions».COMMENTAIRES: Opération «Définir la propriété» en cours sur la cible «Élément: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{6aa63069-e2a1-43d8-bd3c-01586317d391} Propriété: NetbiosOptions».

Pour désactiver NetBIOS par GPO, nous devons exécuter cette commande sur les machines à l'aide d'un script PowerShell !

L'objectif étant de créer une GPO qui va exécuter un script au démarrage de l'ordinateur. Ouvrez la console de gestion des stratégies de groupe pour créer une nouvelle GPO... et laissez-vous guider.

1 - Parcourez les paramètres de GPO de cette façon :

• Configuration ordinateur > Paramètres Windows > Scripts (démarrage/arrêt)

2 - Double-cliquez sur "Démarrage"

3 - Cliquez sur l'onglet "Script PowerShell"

4 - Cliquez sur le bouton "Ajouter"

5 - Cliquez sur le bouton "Parcourir"

6 - Sélectionnez le script PowerShell et validez (vous pouvez le copier-coller à cet emplacement s'il n'est pas encore là, mais l'essentiel étant de bien veiller à utiliser un chemin réseau)

Voilà, la GPO est prête ! Vous pouvez l'appliquer sur les mêmes machines que la GPO pour LLMNR.

C. Désactiver le NetBIOS via le DHCP (option 001)

En tant que complément ou alternative à la méthode par GPO, nous pouvons compter sur notre serveur DHCP pour désactiver le NetBIOS ! En effet, l'option 001 disponible sur les serveurs DHCP sous Windows Server permet d'activer ou désactiver le NetBIOS sur l'interface réseau qui va récupérer l'adresse IP.

• Comment configurer un serveur DHCP sous Windows Server ?

Lorsque cette option n'est pas configurée, le NetBIOS est actif sur l'interface réseau : c'est le comportement par défaut. Nous pouvons le vérifier facilement avec cette commande :

ipconfig /all

Dans la sortie de cette commande, nous pouvons lire : "NetBIOS sur Tcpip : activé".

Désormais, sur le serveur DHCP, nous allons configurer une nouvelle option d'étendue pour désactiver le NetBIOS.

1 - A partir de la console DHCP, accédez à votre étendue et cliquez sur "Options d'étendue". Effectuez un clic droit et choisissez "Configurer les options...".

2 - Cliquez sur l'onglet "Avancé" présent dans la fenêtre "Options étendue".

3 - Pour l'option "Classe de fournisseur", choisissez "Options Microsoft Windows 2000".

4 - Cochez l'option "001 Option Microsoft de désactivation du NetBIOS" pour la configurer sur cette étendue

5 - Attribuez la valeur "0x2" à cette option pour désactiver le NetBIOS.

Note : vous pouvez définir cette option au niveau des options du serveur DHCP pour que toutes vos étendues héritent de la configuration de cette option.

Ainsi, lorsqu'une machine va renouveler son bail DHCP en sollicitant notre serveur DHCP, elle va désactiver le NetBIOS. Pour rappel, vous pouvez libérer un bail DHCP et demander une nouvelle configuration réseau avec ces deux commandes :

ipconfig /releaseipconfig /renew

L'exemple ci-dessous montre bien que le NetBIOS est désactivé, contrairement à l'état de l'interface avant de configurer l'option dans le DHCP.

Cette méthode est pratique et facile à mettre en œuvre si vous utilisez un serveur DHCP sous Windows Server. Par contre, elle a une limite : elle ne s'applique qu'aux clients DHCP. Autrement dit, ceci n'aura aucun effet sur les serveurs ou les machines avec une configuration réseau statique.

VII. Conclusion

LLMNR et NetBIOS sont des protocoles, qui en principe, sont là pour faciliter la vie de tout le monde, mais en réalité, ils représentent un danger. En environnement Active Directory, LLMNR et NetBIOS ne sont pas utiles et doivent être désactivés. À l'inverse, au sein d'un environnement workgroup (groupe de travail), ceci est différent, car il n'y a pas de serveur DNS local donc votre machine Windows peut avoir besoin de ces protocoles pour communiquer, via des noms, avec les autres appareils connectés au réseau local.

Du côté de Microsoft, des changements sont en cours de préparation pour désactiver par défaut certains protocoles, dont le NetBIOS. Plus globalement, l'entreprise américaine veut durcir la configuration de base de Windows 11 en limitant ou désactivant (par défaut) certains protocoles et composants.

Dans un prochain article, nous parlerons d'un autre protocole : mDNS. Lui aussi, c'est un protocole utilisé par Windows (mais aussi d'autres systèmes) pour effectuer de la résolution de noms lorsque la résolution DNS n'est pas disponible ou qu'elle échoue. Ainsi, désactiver LLMNR et NBT-NS ne suffit pas...

• Comment et pourquoi désactiver le protocole mDNS ?

En attendant, intéressez-vous aux protocoles LLMNR et NetBIOS présentés dans l'article du jour ! Par ailleurs, pensez à vous débarrasser d'autres protocoles comme SMBv1 ou encore NTLM.