Retirer LLMNR, NBT-NS, SMBv1 et NTLMv1 ; exiger la signature

Windows conserve une longue traîne de protocoles pour la rétrocompatibilité. Plusieurs d'entre eux donnent à un attaquant présent sur le réseau local exactement ce dont il a besoin :

• LLMNR, NBT-NS et mDNS répondent aux requêtes de noms par diffusion. N'importe qui sur le segment peut répondre « c'est moi » et recevoir une tentative d'authentification contenant l'empreinte NetNTLM de l'utilisateur.
• SMB et LDAP non signés permettent de relayer cette authentification capturée vers un autre serveur en temps réel, ce qui donne souvent un accès administrateur sans rien casser.
• Les réponses LM et NTLMv1 se cassent ou se rétrogradent rapidement.
• SMBv1 n'est plus maintenu et a servi de vecteur à WannaCry et NotPetya.

Chaque section ci-dessous montre comment mesurer d'abord, puis désactiver ou imposer.

LLMNR

Link-Local Multicast Name Resolution est utilisé quand le DNS ne parvient pas à résoudre un nom.

• GPO : Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution = Enabled.
• Registre : HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient EnableMulticast = 0 (DWORD).

LLMNR n'a pratiquement aucun usage légitime dans un domaine. Déployez partout en une seule fois.

Service de noms NetBIOS (NBT-NS)

NBT-NS se configure par carte réseau, ce qui le rend malcommode à gérer :

• DHCP : définissez l'option fournisseur Microsoft 001 Microsoft Disable Netbios Option à 0x2 sur vos étendues DHCP. Les clients DHCP la prennent en compte au renouvellement du bail.
• Cartes statiques / serveurs : définissez NetbiosOptions = 2 sous chaque clé d'interface dans HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}. Un script de démarrage est la méthode habituelle :

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

Vérifiez que plus rien ne dépend des noms NetBIOS : très vieilles applications, certaines imprimantes et certains scanners, configurations reposant sur WINS. Si vous exploitez encore des serveurs WINS, leur décommissionnement fait partie de ce projet.

mDNS et WPAD

• mDNS : les versions actuelles de Windows répondent aussi au DNS multicast. Bloquer l'UDP 5353 entrant avec le pare-feu de l'hôte sur les réseaux gérés est le contrôle le plus fiable ; beaucoup de référentiels définissent aussi EnableMDNS = 0 sous HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters.
• WPAD (Web Proxy Auto-Discovery) permet à un client de rechercher une configuration de proxy par son nom, ce à quoi un attaquant peut répondre. Si vous n'utilisez pas WPAD, désactivez la détection automatique du proxy par stratégie et vérifiez que wpad figure dans la liste globale de blocage des requêtes du serveur DNS (c'est le cas par défaut sur les serveurs DNS Windows ; vérifiez que personne ne l'a retiré avec dnscmd /info /globalqueryblocklist). Si vous utilisez WPAD, publiez un enregistrement DNS wpad faisant autorité pour que personne d'autre ne puisse le revendiquer.

SMBv1

SMBv1 n'est plus installé par défaut depuis Windows 10 1709 et Windows Server 2019, mais les mises à niveau et les anciennes images le perpétuent.

Identifiez qui l'utilise encore en commençant par un audit sur les serveurs de fichiers :

Set-SmbServerConfiguration -AuditSmb1Access $true -Force
# puis lire Microsoft-Windows-SMBServer/Audit, événement 3000 (un client s'est connecté en SMBv1)

Puis supprimez-le :

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart   # postes clients
Remove-WindowsFeature FS-SMB1                                                 # serveurs
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol                 # vérification : False

Les réfractaires typiques sont les imprimantes multifonctions qui numérisent vers un partage, les vieux NAS et les systèmes industriels. Mettez à jour leur micrologiciel ou isolez-les ; ne gardez pas SMBv1 sur tout votre parc pour un seul scanner.

Signature SMB

La signature empêche le relais et l'altération SMB. Réglez-la sur obligatoire des deux côtés :

Chemin : Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Équivalents PowerShell :

Set-SmbClientConfiguration -RequireSecuritySignature $true -Force
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

Les contrôleurs de domaine exigent la signature côté serveur depuis longtemps. Windows 11 24H2 (Entreprise, Professionnel et Éducation) exige désormais la signature par défaut en sortie comme en entrée, et Windows Server 2025 l'exige en sortie : les machines récentes refuseront donc déjà les NAS tiers qui ne signent pas, et la signature obligatoire bloque aussi l'accès invité aux partages ; anticipez-le plutôt que de le découvrir. Pour les partages sensibles, le chiffrement SMB 3 (Set-SmbShare -Name Finance -EncryptData $true) va plus loin.

Signature LDAP et liaison de canal

Les liaisons LDAP non signées et LDAPS sans liaison de canal (channel binding) permettent le relais NTLM vers les contrôleurs de domaine, l'une des cibles de relais les plus dévastatrices.

1. Auditer d'abord. Sur chaque DC, activez la journalisation de diagnostic des événements de l'interface LDAP : HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics 16 LDAP Interface Events = 2. Recherchez ensuite les événements 2889 (un client a effectué une liaison non signée ou une liaison simple en clair) dans le journal Directory Service. L'événement 2887 fournit un décompte récapitulatif quotidien.
2. Exiger la signature : Domain controller: LDAP server signing requirements = Require signing (dans la Default Domain Controllers Policy) et Network security: LDAP client signing requirements = Negotiate signing ou plus strict sur les serveurs membres et postes.
3. Liaison de canal pour LDAPS : Domain controller: LDAP server channel binding token requirements = When supported, puis Always une fois que les événements d'audit (3039, 3040, 3041) ne montrent plus de client incompatible.

NTLM : refuser les anciennes versions, puis réduire le reste

Refuser LM et NTLMv1

Network security: LAN Manager authentication level = Send NTLMv2 response only. Refuse LM & NTLM (registre HKLM\SYSTEM\CurrentControlSet\Control\Lsa LmCompatibilityLevel = 5). Appliquez à toutes les machines, contrôleurs de domaine compris. Définissez aussi Network security: Do not store LAN Manager hash value on next password change = Enabled.

Avant de basculer sur les DC, identifiez les utilisateurs de NTLMv1 : l'événement de sécurité 4624 comporte le champ Package Name (NTLM only) ; filtrez sur NTLM V1 :

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 20000 |
  Where-Object { $_.Message -match 'NTLM V1' } |
  Select-Object TimeCreated, @{n='Detail';e={($_.Message -split "`n" | Select-String 'Workstation Name|Account Name|Source Network Address') -join '; '}}

Auditer et restreindre NTLMv2

• Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all (sur les DC).
• Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts (sur les serveurs).
• Lisez Applications and Services Logs > Microsoft > Windows > NTLM > Operational (événements 8001 à 8004) pour voir quels clients et serveurs utilisent encore NTLM, et pourquoi (généralement une connexion par adresse IP, des SPN manquants ou des appareils hors domaine).

Réduisez-le ensuite : corrigez les SPN et les noms DNS pour que Kerberos fonctionne, ajoutez les utilisateurs à privilèges à Protected Users (plus de NTLM du tout), et appliquez Restrict NTLM: Incoming NTLM traffic = Deny all accounts sur les serveurs qui n'ont aucun client NTLM légitime. Ajoutez Extended Protection for Authentication sur IIS, l'inscription web AD CS et Exchange : elle lie NTLM au canal TLS et met en échec le relais vers ces services.

Ordre des opérations

Liste de contrôle

• LLMNR désactivé par GPO ; NBT-NS désactivé via DHCP et sur les cartes statiques
• mDNS bloqué, WPAD désactivé ou publié de façon faisant autorité
• SMBv1 supprimé ; l'audit n'a montré aucun client restant
• Signature SMB exigée sur les clients et les serveurs
• Signature LDAP exigée, liaison de canal réglée sur Always
• LmCompatibilityLevel 5 partout, empreintes LM non stockées
• NTLM audité ; Protected Users et EPA réduisent la surface d'attaque restante

Ces changements ferment les attaques qui transforment « quelqu'un s'est branché sur le réseau » en « quelqu'un possède le domaine ». Associez-les à des règles de pare-feu sur les hôtes qui empêchent purement et simplement les postes de travail de se parler en SMB.