Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

NBT-NS (NetBIOS Name Service)

ad

Définition

NBT-NS (NetBIOS Name Service) est un protocole de résolution de noms hérité, fonctionnant sur le port UDP 137, permettant à des machines Windows de résoudre les noms NetBIOS d'autres hôtes du réseau local par diffusion (broadcast) lorsque la résolution DNS échoue ou n'est pas configurée. Historiquement l'un des tout premiers mécanismes de résolution de noms de l'écosystème Windows, antérieur même à LLMNR, NBT-NS reste activé par défaut dans de très nombreux environnements Active Directory malgré son obsolescence technique, en raison de dépendances applicatives héritées ou d'une simple absence de durcissement. Son fonctionnement par diffusion sans authentification du répondant constitue le vecteur d'empoisonnement le plus ancien et le plus documenté des environnements Windows : tout hôte du réseau local peut répondre à une requête NBT-NS non résolue en prétendant être la cible recherchée, capturant ainsi l'authentification NTLM initiée par le client qui tente de s'y connecter. Des outils comme Responder exploitent systématiquement ce protocole en combinaison avec LLMNR et mDNS pour maximiser les chances de capture d'authentifications sur un segment réseau donné. La désactivation de NBT-NS, réalisable via les paramètres TCP/IP avancés de chaque interface réseau ou par GPO à l'échelle du domaine, constitue une mesure de durcissement de base recommandée dans quasiment tous les guides de sécurisation Active Directory.

Rôle et fonctionnement

Lorsqu'un poste Windows résout un nom, il interroge son cache et son fichier hosts, puis le DNS, puis LLMNR (UDP 5355) et enfin NBT-NS. Ce dernier diffuse la requête en broadcast sur UDP 137, dans les limites du sous-réseau : n'importe quelle machine du segment peut y répondre. Ce recours ultime se déclenche surtout sur des noms de partages mal saisis ou des suffixes DNS obsolètes.

Utilisation offensive

Un attaquant présent sur le même VLAN lance Responder ou Inveigh et répond à toutes les requêtes NBT-NS en usurpant l'hôte demandé. La victime lui présente alors une authentification NTLM :

  • Capture du défi-réponse NetNTLMv1/v2, cassable hors ligne (hashcat, mode 5600) — ce n'est pas un condensat réutilisable en pass-the-hash.
  • Relais NTLM vers SMB ou LDAP quand la signature n'est pas imposée, menant à l'exécution de code ou à des droits sur l'annuaire.
  • Variante WPAD : le même empoisonnement impose un proxy et collecte les identifiants HTTP.

Détection

La signature caractéristique est un hôte unique répondant positivement à de nombreux noms distincts, comportement impossible pour un poste légitime. Des sondes réseau (Zeek, Suricata) captent ce trafic bien mieux que les journaux Windows. Émettre périodiquement des requêtes leurres portant un nom volontairement inexistant offre une détection quasiment sans faux positif : toute réponse trahit un empoisonneur. Le journal Microsoft-Windows-NTLM/Operational corrobore côté authentification.

Durcissement

  • Désactiver NetBIOS over TCP/IP via l'option DHCP 001 (valeur 2) ou la clé NetbiosOptions=2 des interfaces NetBT.
  • Désactiver aussi LLMNR par GPO : neutraliser NBT-NS seul laisse ouverte la voie multicast, erreur la plus fréquente.
  • Imposer la signature SMB, privilégier Kerberos, corriger les suffixes DNS pour que le repli ne survienne jamais et décommissionner WINS.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis