Désactiver LLMNR, NBT-NS, mDNS et WPAD dans AD

Lorsque DNS ne parvient pas à résoudre un nom, Windows interroge le réseau local : via LLMNR (UDP 5355), NetBIOS Name Service (UDP 137) et, sur les versions actuelles, DNS multicast (UDP 5353). Rien n'authentifie la réponse. N'importe qui sur le segment exécutant un outil d'empoisonnement comme Responder ou Inveigh peut répondre « c'est moi » ; la victime se connecte alors et envoie une authentification NTLM, capturée pour être cassée ou relayée en direct. WPAD aggrave la situation : les navigateurs et WinHTTP recherchent wpad automatiquement, la victime n'a donc même pas besoin de faire une faute de frappe.

C'est l'empoisonnement LLMNR, présent dans presque tous les tests d'intrusion internes. Le pilier NTLM et protocoles hérités présente la stratégie LLMNR et un script NetBIOS par carte réseau. Ce guide couvre les quatre protocoles, les options qui résistent à l'ajout de nouvelles cartes réseau et aux équipements hors domaine, et la manière de prouver le résultat depuis le réseau plutôt qu'à partir d'une clé de registre.

Mesurer : ce qui répond aujourd'hui

Avant de modifier quoi que ce soit, établissez une référence du volume de trafic de repli. Une capture de paquets sur quelques VLAN utilisateurs (filtre sur UDP 5355, 137 et 5353) montre quels hôtes envoient des requêtes et pour quels noms. Ce sont les noms qui sont utiles : ils révèlent des fautes de frappe dans les lecteurs mappés, des cibles de raccourcis obsolètes et des scripts qui pointent vers des serveurs décommissionnés. Corrigez-les dans DNS ou dans la configuration qui y fait référence, car chacun d'eux est une occasion d'empoisonnement garantie.

Vérifiez quels hôtes ont déjà désactivé ces protocoles :

$targets = (Get-ADComputer -Filter 'OperatingSystem -like "*Windows*"' -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com').DNSHostName
Invoke-Command -ComputerName $targets -ErrorAction SilentlyContinue -ScriptBlock {
    $llmnr = (Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue).EnableMulticast
    $mdns  = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters' -ErrorAction SilentlyContinue).EnableMDNS
    $nbt   = Get-CimInstance Win32_NetworkAdapterConfiguration -Filter 'IPEnabled=True' |
             Select-Object -ExpandProperty TcpipNetbiosOptions
    [PSCustomObject]@{ Host = $env:COMPUTERNAME; LLMNR = $llmnr; mDNS = $mdns; NetBIOS = ($nbt -join ',') }
} | Export-Csv .\name-resolution-posture.csv -NoTypeInformation

Pour TcpipNetbiosOptions, 0 signifie « utiliser le paramètre DHCP », 1 activé, 2 désactivé. Une valeur LLMNR ou mDNS vide correspond à la valeur par défaut, c'est-à-dire activé.

Désactiver LLMNR

Stratégie de groupe :

Computer Configuration > Policies > Administrative Templates > Network > DNS Client
  Turn off multicast name resolution = Enabled

Cela écrit EnableMulticast = 0 sous HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient. Appliquez-la à chaque UO contenant des ordinateurs Windows, serveurs compris. Les contrôleurs de domaine et les serveurs n'ont pratiquement jamais besoin de résolution de noms de repli.

Désactiver NetBIOS sur TCP/IP

NetBIOS se configure par carte réseau : c'est pourquoi les scripts exécutés une seule fois ratent les stations d'accueil, les cartes VPN et les nouvelles cartes réseau. Superposez plusieurs contrôles.

Option DHCP pour les clients dynamiques

Sur les serveurs DHCP Windows, définissez l'option fournisseur Microsoft sur chaque étendue ou au niveau du serveur :

# Classe fournisseur "Microsoft Windows 2000 Options", option 001 "Microsoft Disable Netbios Option", valeur 2
Set-DhcpServerv4OptionValue -ComputerName dhcp01.corp.example.com -ScopeId 10.20.0.0 `
    -VendorClass 'Microsoft Windows 2000 Options' -OptionId 1 -Value 2

Les clients dont TcpipNetbiosOptions = 0 (valeur par défaut) désactivent alors NetBIOS sur cette carte au prochain renouvellement de bail. Les serveurs DHCP tiers peuvent envoyer la même option propre au fournisseur ; consultez la documentation de votre éditeur pour la syntaxe.

Registre et GPO pour les cartes statiques et VPN

Pour les cartes qui n'utilisent pas le DHCP Windows, définissez NetbiosOptions = 2 sur chaque interface sous HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}. Un script de démarrage ou des éléments de registre Group Policy Preferences avec une collection couvrant toutes les clés d'interface maintiennent le réglage sur les nouvelles cartes :

Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces' |
    ForEach-Object { Set-ItemProperty -Path $_.PSPath -Name NetbiosOptions -Value 2 -Type DWord }

Les fichiers ADMX récents de Windows 11 incluent une stratégie « Configure NetBIOS settings » sous le nœud DNS Client. Si tout votre parc la prend en charge, c'est une option plus propre que les scripts ; comparez le texte « supported on » de la stratégie avec vos builds clientes les plus anciennes.

En complément, définir NodeType = 2 (P-node) sous HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters bloque les requêtes de noms par diffusion, même là où NetBIOS reste activé.

Désactiver mDNS

Définissez directement le paramètre du client DNS, via Group Policy Preferences :

HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
  EnableMDNS (DWORD) = 0

Les modèles ADMX récents de Windows 11 exposent aussi une stratégie mDNS sous le nœud DNS Client. Pilotez celle-ci en premier : certaines imprimantes, certains appareils de diffusion et certaines fonctions de découverte entre pairs dépendent de mDNS.

Bloquer WPAD

Les recherches WPAD proviennent des navigateurs configurés sur « Détecter automatiquement les paramètres » et du service de proxy automatique WinHTTP. Une réponse malveillante peut arriver par quatre voies, et chacune nécessite son propre contrôle :

1. Repli multicast (LLMNR, NetBIOS, mDNS) : traité par les sections précédentes.
2. DNS : par défaut, les utilisateurs authentifiés peuvent créer des enregistrements dans les zones intégrées à AD, y compris wpad. La liste globale de blocage des requêtes du serveur DNS empêche les serveurs DNS Microsoft de répondre pour wpad et isatap, même si un tel enregistrement existe. Elle est activée par défaut, mais elle est régulièrement vidée pour faire fonctionner un déploiement WPAD légitime.
3. Option DHCP 252 : assurez-vous qu'aucune étendue ne la publie, sauf si vous utilisez délibérément WPAD.
4. La détection automatique côté client elle-même : si vous n'utilisez pas WPAD, désactivez la détection automatique du proxy dans les navigateurs via leurs stratégies et définissez le proxy explicitement ou avec une URL PAC.

# Sur chaque serveur DNS : vérifier que la liste de blocage est active et contient wpad
Get-DnsServerGlobalQueryBlockList -ComputerName dc01.corp.example.com

# La restaurer si quelqu'un l'a vidée
Set-DnsServerGlobalQueryBlockList -ComputerName dc01.corp.example.com -Enable $true -List 'wpad','isatap'

# Rechercher les enregistrements wpad créés dans les zones intégrées à AD
Get-DnsServerZone -ComputerName dc01.corp.example.com | Where-Object { $_.IsDsIntegrated -and -not $_.IsReverseLookupZone } |
    ForEach-Object { Get-DnsServerResourceRecord -ComputerName dc01.corp.example.com -ZoneName $_.ZoneName -Name 'wpad' -ErrorAction SilentlyContinue }

Si vous vous appuyez sur WPAD, publiez un enregistrement wpad légitime que vous contrôlez, retirez uniquement wpad de la liste de blocage et conservez isatap. Quiconque peut écrire cet enregistrement contrôle le proxy de vos utilisateurs : verrouillez donc son ACL. Le volet DNS de ce sujet côté contrôleurs de domaine s'intègre naturellement au reste de votre durcissement des contrôleurs de domaine.

Les équipements que vous ne gérez pas

La stratégie de groupe n'atteint que les machines Windows jointes au domaine. L'outil d'empoisonnement se moque de savoir qui pose la question, et la victime qui compte est celle qui envoie des identifiants en réponse : les équipements non gérés méritent donc un examen.

• Les machines Windows hors domaine (portables de prestataires, hôtes de laboratoire, bornes) gardent les trois protocoles activés. L'option NetBIOS DHCP les atteint quand même, mais pas LLMNR ni mDNS. Un contrôle d'accès réseau ou un VLAN séparé pour les équipements non gérés limite ce qu'ils peuvent atteindre et ce qu'un outil d'empoisonnement sur leur segment peut collecter.
• macOS et Linux s'appuient sur mDNS (Bonjour, Avahi) par conception, et certaines distributions Linux livrent un répondeur LLMNR dans systemd-resolved. Ils envoient du NTLM moins souvent que Windows, mais les hôtes Linux intégrés au domaine et les Mac avec des montages SMB peuvent le faire. Configurez LLMNR=no et MulticastDNS=no dans systemd-resolved sur les hôtes que vous gérez, et utilisez votre MDM pour macOS.
• Les serveurs en DMZ et sur les réseaux d'administration se trouvent souvent hors du périmètre GPO principal. Vérifiez que la même base de référence est liée à leurs UO, ou appliquée localement avec LGPO s'ils ne sont pas joints au domaine.

La segmentation compte aussi en elle-même. La résolution de noms multicast est limitée au lien local : un outil d'empoisonnement doit se trouver dans le même domaine de diffusion que la victime. Des VLAN utilisateurs de petite taille, l'isolation des clients sur le Wi-Fi et des VLAN privés pour les serveurs réduisent l'audience d'un outil d'empoisonnement qui parviendrait sur le réseau, ce qui limite les dégâts causés par les équipements que vous ne pouvez pas configurer.

Vérifier

Les contrôles de registre sont nécessaires mais pas suffisants. Vérifiez depuis le réseau :

• Relancez le script d'état : LLMNR et mDNS doivent valoir 0, NetBIOS 2 sur toutes les cartes.
• Refaites la capture de paquets sur les mêmes VLAN. Vous ne devez voir aucune requête sur UDP 5355 et 5353 provenant d'hôtes Windows gérés, ni aucune requête de nom NetBIOS sur UDP 137.
• Depuis un client géré, Resolve-DnsName -Name doesnotexist01 -LlmnrNetbiosOnly doit renvoyer une erreur plutôt qu'une réponse.
• Resolve-DnsName wpad.corp.example.com doit échouer sur chaque serveur DNS.
• Conservez une détection pour les machines que vous ne gérez pas : un hôte canari qui interroge périodiquement un nom aléatoire inexistant via LLMNR et NetBIOS ne recevra de réponse que si un outil d'empoisonnement est présent sur le segment. Microsoft Defender for Identity et la plupart des produits NDR alertent aussi sur ces réponses. Associez cela à des honeytokens pour détecter l'utilisation d'identifiants capturés.

Ce qui casse

• La résolution de noms courts pour les hôtes sans enregistrement DNS : anciens serveurs à IP statique qui ne se sont jamais enregistrés, machines de laboratoire et équipements sur des réseaux sans la bonne liste de recherche de suffixes DNS. Corrigez côté DNS, pas la stratégie.
• Les applications héritées qui utilisent les noms NetBIOS ou le service Explorateur d'ordinateurs (exploration du voisinage réseau, certaines anciennes applications métier et serveurs de licences).
• La découverte mDNS des imprimantes, appareils de diffusion, de certains équipements de salles de réunion et des fonctions pair-à-pair, s'ils sont utilisés sur les réseaux d'entreprise.
• La configuration de proxy basée sur WPAD : les clients qui dépendent de la détection automatique perdent leur proxy si l'entrée de la liste de blocage est appliquée sans alternative ; configurez d'abord une URL PAC ou un proxy explicite.
• Les réseaux domestiques et d'hôtel pour les portables : les utilisateurs accèdent parfois à des appareils grand public par leur nom ; c'est une note pour le support, pas une raison de conserver ces protocoles.

Pour aller plus loin : le thème NTLM & protocoles hérités, exiger la signature SMB et la signature et la liaison de canal LDAP pour que tout ce qui serait encore capturé ne puisse pas être relayé, et l'entrée de glossaire Relais NTLM pour la chaîne d'attaque de bout en bout.