Bloquer le relais NTLM : signature LDAP, SMB et LLMNR
Durcir la signature LDAP, la liaison de canal LDAP et la signature SMB, et désactiver LLMNR/NBT-NS pour fermer les chemins de relais NTLM vers les DC.
Le relais NTLM reste l'un des chemins les plus fiables vers la compromission d'un domaine, car de nombreux environnements AD autorisent encore les liaisons LDAP non signées, le SMB non signé et des protocoles de résolution de noms hérités qui divulguent des identifiants à quiconque écoute sur le segment local. Aucune des corrections décrites ici ne nécessite de nouvelle infrastructure : ce sont des valeurs de registre, des paramètres de stratégie de groupe et une journalisation d'audit que vous pouvez activer dès cette semaine. Ce guide couvre le verrouillage de la signature LDAP et SMB, la suppression de LLMNR/NBT-NS et le retrait de NTLMv1, avec des étapes de vérification et une liste claire de ce qui casse.
Pourquoi LLMNR et NBT-NS rendent possible le relais NTLM
LLMNR (Link-Local Multicast Name Resolution) et NBT-NS (NetBIOS Name Service) permettent aux hôtes Windows de résoudre des noms lorsque DNS échoue, en diffusant une requête sur le sous-réseau local. N'importe quel hôte de ce segment peut répondre : la réponse n'est pas authentifiée. Un attaquant qui répond à ces diffusions pousse la victime à s'authentifier auprès de lui en NTLM, ce qui lui permet de capturer un hash ou de relayer la tentative d'authentification en direct vers un service cible comme LDAP ou SMB. Désactiver ces deux protocoles supprime le point d'appui le plus simple pour la collecte d'identifiants dans la plupart des tests d'intrusion internes.
Désactiver LLMNR
Chemin de stratégie de groupe :
Computer Configuration > Policies > Administrative Templates > Network > DNS Client
Turn Off Multicast Name Resolution: EnabledValeur de registre équivalente :
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
EnableMulticast (DWORD) = 0Désactiver NBT-NS
NBT-NS ne dispose d'aucun paramètre GPO natif ; désactivez-le carte par carte via WMI, idéalement déployé par un script de démarrage ou une tâche planifiée afin que le réglage s'applique aussi aux nouvelles cartes réseau :
# Désactiver NetBIOS sur TCP/IP sur toutes les cartes (0 = par défaut/activé via DHCP, 1 = activé, 2 = désactivé)
Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True" |
ForEach-Object { $_.SetTcpipNetbios(2) }Vérification :
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMulticast
Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True" |
Select-Object Description, TcpipNetbiosOptionsSignature LDAP et liaison de canal LDAP
Les liaisons LDAP non signées permettent à un attaquant de relayer une authentification NTLM capturée directement dans une session LDAP sur un contrôleur de domaine, ce qui suffit souvent à s'ajouter à un groupe privilégié ou à lire des attributs confidentiels. Deux paramètres indépendants ferment cette porte : la signature du serveur LDAP (LDAPServerIntegrity) et la liaison de canal LDAP (LdapEnforceChannelBinding), cette dernière fermant le chemin de relais propre à LDAPS/TLS que la signature seule ne couvre pas.
À définir sur chaque contrôleur de domaine :
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
LDAPServerIntegrity (DWORD) = 2 ; 1 = None, 2 = Require signing
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
LdapEnforceChannelBinding (DWORD) = 2 ; 0 = Never, 1 = When supported, 2 = AlwaysLes deux valeurs peuvent être déployées par une préférence de registre GPO ciblant l'UO Domain Controllers, ou définies directement :
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name LDAPServerIntegrity -Value 2
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name LdapEnforceChannelBinding -Value 2Identifier les clients non conformes avant l'application stricte
Avant de configurer LDAPServerIntegrity pour exiger la signature, activez la journalisation de diagnostic sur le DC et analysez le journal Directory Service pendant une fenêtre de déploiement (deux à quatre semaines en général) :
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" -Name "16 LDAP Interface Events" -Value 2Surveillez ces ID d'événements Directory Service, qui identifient précisément les clients et services qui se lient sans signature ni liaison de canal :
| ID d'événement | Signification |
|---|---|
| 2886 | Le DC n'est pas configuré pour exiger la signature LDAP — informatif, à corriger avant l'application stricte |
| 2887 | Nombre de liaisons SASL non signées et de liaisons simples en clair acceptées au cours des dernières 24 heures |
| 2888 | La signature est imposée — nombre de liaisons non signées rejetées au cours des dernières 24 heures |
| 2889 | Un client précis a effectué une liaison SASL non signée ou une liaison simple en clair — journalise l'IP et le compte du client : c'est votre liste de remédiation |
| 3039 | Un client précis s'est lié via TLS sans jeton de liaison de canal valide (3040 est le décompte sur 24 heures, 3041 indique que la liaison de canal n'est pas imposée) |
Get-WinEvent -LogName "Directory Service" | Where-Object { $_.Id -in 2887,2889,3039 } |
Select-Object TimeCreated, Id, Message | Format-ListNe passez LDAPServerIntegrity et LdapEnforceChannelBinding à leurs valeurs strictes (2) qu'une fois que les événements 2889 et 3039 ont cessé d'apparaître, ou que les sources restantes sont des exceptions acceptées. Consultez Liaison de canal LDAP pour comprendre comment la liaison rattache la session LDAP au canal TLS.
Signature SMB
Le relais SMB fonctionne comme le relais LDAP : une authentification NTLM capturée est rejouée contre un serveur de fichiers ou, pire, contre la pile SMB d'un contrôleur de domaine. Exiger la signature SMB signifie qu'une session relayée échoue aux contrôles d'intégrité et est abandonnée.
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
Microsoft network server: Digitally sign communications (always): Enabled
Microsoft network client: Digitally sign communications (always): EnabledÉquivalents dans le registre :
HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
RequireSecuritySignature (DWORD) = 1
HKLM\SYSTEM\CurrentControlSet\Services\LanManWorkstation\Parameters
RequireSecuritySignature (DWORD) = 1Appliquez d'abord aux contrôleurs de domaine (ce sont les cibles de relais les plus précieuses), puis aux postes de travail et serveurs de fichiers par étapes. Vérifiez :
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature
Get-SmbClientConfiguration | Select-Object RequireSecuritySignatureAuditer et restreindre NTLM
Plutôt que de désactiver NTLM d'un bloc — ce qui casse tout ce qui n'a pas migré vers Kerberos —, utilisez la démarche Restrict NTLM : auditer d'abord, bloquer ensuite.
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
Network security: Restrict NTLM: Audit NTLM authentication in this domain: Enable all
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers: Audit allLes événements d'audit (ID 8001-8004) sont écrits dans le journal Microsoft-Windows-NTLM/Operational, et non dans le journal System. Analysez-les sur un cycle d'activité complet, établissez une liste d'autorisation des services qui ont encore légitimement besoin de NTLM, puis passez de Audit à Deny pour tout le reste :
Network security: Restrict NTLM: NTLM authentication in this domain: Deny all
Network security: Restrict NTLM: Add server exceptions in this domain: <legacy app servers>Désactiver NTLMv1
NTLMv1 est cryptographiquement faible et doit être désactivé purement et simplement ; seul NTLMv2 doit rester disponible comme solution de repli pour les équipements qui ne peuvent pas encore utiliser Kerberos.
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
Network security: LAN Manager authentication level: Send NTLMv2 response only. Refuse LM & NTLMRegistre :
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
LmCompatibilityLevel (DWORD) = 5Vérification :
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevelCe qui casse
- Signature LDAP/liaison de canal : anciens scanners réseau, imprimantes/multifonctions avec recherche d'annuaire LDAP intégrée, certaines appliances de sauvegarde et de supervision, et passerelles d'identité tierces qui se lient sans signature. Les événements 2886-2889 les identifient avant l'application stricte.
- Signature SMB : NAS très anciens limités à SMBv1 et certains systèmes industriels/embarqués ; la signature a aussi un léger coût en débit sur les gros transferts de fichiers via des liaisons lentes.
- Désactivation de LLMNR/NBT-NS : les environnements qui s'appuient encore sur la résolution de noms NetBIOS pour des noms courts hérités (applications antérieures à DNS, certains logiciels métier) peuvent subir des échecs de résolution intermittents — vérifiez d'abord la couverture DNS.
- LmCompatibilityLevel = 5 : tout équipement ou application codé en dur pour NTLMv1, typiquement de très vieux copieurs, certains équipements SCADA/ICS et des clients SMB non Windows non mis à jour.
Pour un durcissement complémentaire, consultez Durcissement de Kerberos et Durcissement des contrôleurs de domaine. La technique de relais elle-même est détaillée dans Relais NTLM.
Questions fréquentes
L'application stricte de la signature LDAP va-t-elle casser quelque chose ?
Elle bloque toute application ou appliance qui se lie à LDAP en clair sans prendre en charge la signature, notamment certains anciens scanners réseau, imprimantes et connecteurs d'identité tiers. Testez en mode audit avec les événements 2886-2889 avant de l'imposer.
Quelle est la différence entre la signature LDAP et la liaison de canal LDAP ?
La signature LDAP (LDAPServerIntegrity) protège le trafic LDAP sur le port 389 contre l'altération et le relais. La liaison de canal (LdapEnforceChannelBinding) rattache une session LDAPS (port 636) au canal TLS sous-jacent, ce qui ferme un chemin de relais distinct que la signature seule ne couvre pas.
Puis-je désactiver complètement NTLM ?
Dans la plupart des environnements, non : des applications héritées, des équipements en groupe de travail et certains services VPN ou d'impression dépendent encore de NTLM. La démarche réaliste consiste à auditer, puis à appliquer des stratégies Restrict NTLM limitées à ce que vous avez vérifié comme sûr, tout en désactivant NTLMv1 partout.
Bloquer le relais NTLM : signature LDAP, SMB et LLMNR